Nein. Die API-Schlüssel müssen im Klartext gespeichert werden.

Es handelt sich nicht um Kennwörter, sondern um kryptografische Schlüssel. Diese Schlüssel werden beispielsweise zur Authentifizierung von Anforderungen (mithilfe von SHA1-HMAC) verwendet. Der Server muss den Kryptoschlüssel kennen, um die kryptografischen Algorithmen anwenden zu können.

Daher muss der API-Schlüssel im Klartext auf dem Server gespeichert werden. Wenn der Server nur einen Hash des API-Schlüssels gespeichert hat, konnte er die Authentizität von Nachrichten vom Client nicht überprüfen oder an den Client gesendete Nachrichten nicht authentifizieren.

Hashing ist kein Speicher; es zerstört irreversibel Daten. Wir können mit dem Aufrufen von Passwort-Hashing als "Passwortspeicher" davonkommen, denn wenn wir das Passwort tatsächlich benötigen, haben wir einen praktischen menschlichen Operator, der es eingibt. Wenn wir das Passwort hashen, speichern wir das Passwort nicht, sondern nur ein Token Ausreichend, um das eingegebene Kennwort zu überprüfen.

Ein API-Schlüssel muss so gespeichert werden, dass er unbeaufsichtigt wieder verwendet werden kann. Der Server muss es wirklich speichern , anstatt sich nur an einen Geist zu erinnern, da er den echten Schlüssel benötigt, um auf die API zuzugreifen.

Hier und an anderen Orten scheint es ein wenig Verwirrung zu geben, daher füge ich diese Antwort in der Hoffnung hinzu, dass sie die Situation für andere Benutzer klären wird.

Dort Es gibt zwei Arten von API-Geheimnissen, die möglicherweise verwendet werden.

Der Anwendungsfall, den die meisten Antworten auf dieser Seite behandeln, ist ein geheimer Schlüssel, der zum Signieren und Überprüfen von Nachrichten verwendet wird unter Verwendung eines Algorithmus wie HMAC. In diesem Fall benötigen sowohl der Client als auch die API den tatsächlichen Wert des Schlüssels, um eine Signatur der Nachricht zu erstellen. Der Server vergleicht dann die von ihm generierte Signatur mit der vom Client gesendeten Signatur und kann die Nachricht überprüfen. Wie oben erwähnt, kann dies nicht funktionieren, wenn der ursprüngliche Schlüssel auf dem Server nicht reproduzierbar ist. Nach dem erstmaligen Teilen des Schlüssels mit dem Client (über einen verschlüsselten Kanal) muss der Schlüssel nie wieder zwischen Client und Server übertragen werden.

Das andere gemeinsame API-Client-Geheimnis ist lediglich ein Geheimnis Anmeldeinformationen (wie Sie möglicherweise in einer typischen OAuth2-Zugriffstokenanforderung sehen). Dieser Berechtigungsnachweis wird bei jeder Anforderung übertragen und sollte daher nur über einen verschlüsselten Kanal (z. B. HTTPS) übertragen werden. In diesem Fall muss der Server nur genügend Informationen aufbewahren, um zu überprüfen, ob der vom Client angegebene geheime Wert korrekt ist, sodass das Geheimnis gehasht werden kann und sollte. In diesem Fall fungiert das Geheimnis effektiv als Passwort, und daher sollten die gleichen Vorsichtsmaßnahmen getroffen werden.

Haftungsausschluss: Ich bin kein Sicherheitsforscher, und Sie sollten dies unbedingt genauer untersuchen und jedes Thema, bevor Sie blindlings den Ratschlägen zu diesem StackExchange folgen.

tl; dr Der wichtigste Aspekt ist, dass verschiedene APIs das Geheimnis auf unterschiedliche Weise verwenden können . Es ist wichtig zu verstehen, wie Ihre API das Client-Geheimnis verwendet, um Best Practices für das Speichern zu bewerten.

Das Hashing der API-Token wäre zwar sicherer, stellt jedoch ein Usability-Problem dar: Die Token sind lang und zufällig und müssten dem Benutzer vor dem Hashing nur einmal mitgeteilt werden. Dies macht es etwas schwierig, sie mit einem Hash zu sichern.

Mein Vorschlag für ein sicheres Szenario lautet wie folgt:

1. Generieren Sie ein zufälliges salt Wert und speichern Sie ihn in der Datenbank. Dieses Salt darf nicht gleich dem Passwort des Benutzers sein. Salt.
2. Nehmen Sie das Klartext-Passwort des Benutzers und berechnen Sie KDF (Passwort, Salt) , wobei KDF ist eine Schlüsselableitungsfunktion wie bcrypt. Rufen Sie den resultierenden Wert k auf.
3. Generieren Sie einen API-Schlüssel.
4. Verschlüsseln Sie den API-Schlüsselwert mit AES unter Verwendung von k as den Schlüssel und speichern Sie den Chiffretext in der Datenbank.
5. Verwerfen Sie den Klartext-API-Schlüssel und k .
ol>

Wenn sich der Benutzer anmeldet, Die Webanwendung kennt ihr Kennwort und berechnet damit k , mit dem der API-Schlüssel entschlüsselt und angezeigt wird.

Wenn der Benutzer die API verwenden möchte, Sie müssen k sowie den Klartext-API-Schlüssel über SSL senden. Die Webanwendung kann dann den gespeicherten API-Schlüsselwert mit k entschlüsseln und mit dem angegebenen API-Schlüssel vergleichen. Wenn sie übereinstimmen, ist es gültig. Dies ermöglicht die Verwendung von API-Schlüsseln, ohne dass die App das Kennwort des Benutzers speichern muss.

Wenn ein Angreifer die Datenbank verletzt, muss er das Kennwort des Benutzers knacken, um k zu berechnen.

Ich habe meine eigenen zwei Cent eingezahlt, weil ein Problem noch nicht erwähnt wurde. Insbesondere stimme ich dem zu, was @NickSloan gesagt hat, aber mit einer weiteren Einschränkung.

Es gibt einen weiteren wichtigen Unterschied zwischen einem API-Schlüssel und einem Kennwort. API-Schlüssel sind für Ihre Site eindeutig. Der Teil, der die Passwortsicherheit so wichtig macht, ist die Passwortfreigabe. Wenn jemand das Kennwort erhält, das ein Benutzer auf Ihrer Website gespeichert hat, ist nicht nur Ihre Website gefährdet, sondern jede andere Website, für die der Benutzer dieses Kennwort (und die E-Mail-Adresse / den Benutzernamen) verwendet hat. Viele Benutzer verwenden Kennwörter auf kritischen Websites wieder: Banken, soziale Medien, E-Mails usw. Dies bedeutet, dass bei einer guten Kennwortsicherheit weniger der Zugriff auf Ihre Website als vielmehr der Schutz Ihrer Benutzer auf anderen Websites geschützt ist. Wir können Benutzer nicht dazu zwingen, die Sicherheit besser zu machen, daher müssen wir das Schlimmste annehmen und zusätzliche Schritte unternehmen, um ihre eigene Privatsphäre zu schützen.

Ein API-Schlüssel ist ein völlig anderes Szenario, da er nur für gilt deine Seite. Wenn es gestohlen wird, erhält der Angreifer Zugriff auf Ihre Website, erhält jedoch nichts, was er gegen die Bank / E-Mail / etc. Dieser Person nutzen kann. Dies bedeutet, dass das Risiko für API-Schlüssel tatsächlich niedriger ist als das für Kennwörter. Sie befinden sich nicht ganz im selben Bereich: API-Schlüssel ähneln eher Sitzungskennungen als Kennwörtern.

Wenn Sie verstehen, dass diese eher Sitzungskennungen als Kennwörtern ähneln, erhalten Sie einige praktische Einblicke in den richtigen Schutz solcher Kennungen Schlüssel. Beachten Sie, dass die folgende Diskussion auf API-Schlüssel für Dinge wie OAuth-Anmeldeinformationen und nicht auf Verschlüsselungsanmeldeinformationen anwendbar ist (wie von @NickSloan in seiner Antwort erläutert).

Die größten Bedrohungen für Passwörter sind Phishing-Angriffe und gehackte Datenbanken. Deshalb speichern wir sie in unseren Datenbanken. Die größten Bedrohungen für API-Schlüssel sind dieselben wie für Sitzungsschlüssel: Schwachstellen in Front-End-Anwendungen wie XSS-Schwachstellen, MIM und dergleichen. Es ist wichtig zu beachten, dass die Front-End-Anwendung das Kennwort in unverschlüsselter Form benötigt, sodass das Hashing des API-Schlüssels Ihnen nichts bringt, wenn die Person, die es am wahrscheinlichsten gestohlen hat, es im Klartext benötigt.

Stattdessen schützen Sie eine Sitzungskennung (oder ein OAuth-Token oder einen clientspezifischen API-Schlüssel) hauptsächlich, indem Sie den Client verfolgen. Wenn eine Sitzungskennung über XSS oder andere Mittel vom Client gestohlen wird, besteht ein typisches Ergebnis darin, dass diese Kennung vom Angreifer auf einem neuen Gerät verwendet wird. Das bedeutet, dass plötzlich ein alter Schlüssel mit einem neuen Benutzeragenten angezeigt wird. Eine solche Änderung ist leicht zu erkennen und zu beheben: Alle API-Schlüssel werden sofort ungültig. Insbesondere bei OAuth-Anfragen ist dies für den Benutzer sehr schmerzlos: Er meldet sich einfach wieder an und erhält sofort einen neuen, während jemand, der nur den Schlüssel gestohlen hat (und kein Passwort hat), wieder am Zeichenbrett sitzt .

Dies ist eine häufig genug vorkommende Verteidigungsmaßnahme, bei der ein intelligenterer Hacker auch versucht, den mit dem gestohlenen Schlüssel verknüpften Benutzeragenten aufzuzeichnen und in allen zukünftigen Anforderungen zu verwenden wenn derselbe Benutzer Anforderungen von mehreren IP-Adressen hat. Wie alles andere auf der Welt kann dies ein Katz-und-Maus-Spiel sein, aber es gibt einige wichtige Take-Aways:

1. Ein API-Schlüssel / OAuth-Token / Sitzungs-ID ist Eigentlich nur eine Möglichkeit, sich an einen Benutzer auf einem bestimmten Gerät zu erinnern, damit er nicht auf jeder Seite sein Passwort eingeben muss. Im Zweifelsfall können Sie daher einfach alle autorisierten Schlüssel löschen und den Benutzer zwingen, sich erneut anzumelden.
2. In allen drei Fällen ist es wichtig, eine aktive Sicherheit in Bezug auf diese Dinge zu haben und zu erkennen / zu reagieren, wenn etwas faul passiert, da der Verlust von Schlüssel / Token / ID zu einer Gefährdung eines Kontos führt. Wenn Sie jemals von Facebook / Google / etc Benachrichtigungen über jemanden erhalten haben, der versucht, sich aus Mexiko in Ihr Konto einzuloggen, liegt dies daran, dass ein Sicherheitsbeamter irgendwo seine Arbeit richtig macht.
3. Die primären Angriffsmethoden für Keys / Token / IDs unterscheiden sich von denen von Passwörtern. Möglicherweise möchten Sie sie weiterhin in Ihrer Datenbank hashen (auch hier handelt es sich nicht um Verschlüsselungsdaten, die im Klartext vorliegen müssen), aber Sie können sie nicht einfach in Ihrer Datenbank hashen und sich selbst als sicher bezeichnen. Sie müssen sicherstellen, dass sie gegen eine ganze Reihe neuer Angriffsmethoden geschützt sind. Wenn Sie sie nur als Passwörter betrachten, werden Sie einige wichtige Teile des Gesamtbildes übersehen.
ol>

Einer der Hauptgründe, warum Kennwörter vor dem Speichern gehasht werden, ist der Schutz vor einem Angreifer, der einen schreibgeschützten Zugriff auf die Datenbank erhält . Auf diese Weise kann ein Angreifer, wenn er die Liste der Anmeldeinformationen erhält, diese immer noch nicht direkt verwenden, da die Kennwörter gehasht / gesalzen sind.

Und dies ist nicht nur ein theoretisches Problem, das wir ' Wenn Sie versuchen, diese Art von Angriffen zu lösen, passieren sie ( auch für wichtige Akteure in der Branche), und korrektes Hashing hilft dabei, die Auswirkungen eines Angriffs abzuschwächen.

Wenn Sie Benutzern die Authentifizierung mithilfe eines API-Geheimnisses ermöglichen, wurde das API-Geheimnis effektiv zu einem Kennwort . Aus Sicherheitsgründen sollten sie daher dieselben Schutzmechanismen haben wie normale Kennwörter

Amazon selbst erlaubt jetzt nicht das Abrufen des API-Geheimnisses. Wenn Sie es vergessen haben, müssen Sie nach einem neuen fragen.

Nein, für bestimmte Dienste ist dies nicht in Ordnung.

Implementierung

1. Bei Benutzerverbindung mit Anmeldekennwort Generieren Sie einen aus seinem Kennwort abgeleiteten Schlüssel, um Daten für diesen Benutzer zu verschlüsseln und in einer Sitzung auf dem Server zu speichern.

Auf diese Weise hat jeder Benutzer einen eindeutigen Schlüssel. Dieser abgeleitete Schlüssel darf nicht umkehrbar sein, dies ist der Hauptpunkt. Die Verwendung von hash_mac oder einer anderen Hashing-Methode mit Salt und / oder Hauptschlüssel ermöglicht dies.

2. Verwenden Sie diesen Schlüssel, um das generierte API-Geheimnis mit AES 256 mit einem zufälligen iv für zu verschlüsseln jeder Benutzer.

oder

2.bis Verwenden Sie diesen Schlüssel, um im letzten Moment den echten Verschlüsselungsschlüssel zu generieren und die API-Methode auf die gleiche Weise wie in zu verschlüsseln 2. Um schwebende Kennwörter im Speicher zu vermeiden.

3. Speichern Sie das iv zusammen mit der Benutzer-ID und der App-ID in einer dedizierten Tabelle in der Datenbank.

4. Speichern Sie das verschlüsselte API-Geheimnis in der Datenbank in der entsprechenden Tabelle.

Verwendung

Jetzt, wenn der Benutzer eine Verbindung herstellt In seinem Control Panel können Sie den Schlüssel neu erstellen, das iv abrufen, das API-Geheimnis für diesen Benutzer entschlüsseln und es im Klartext anzeigen. Sie zeigen auch den Schlüssel an und fragen beim API-Aufruf nach beiden, damit Sie das App-Geheimnis überprüfen können.

Wenn Sie vermeiden möchten, den Schlüssel anzuzeigen und ihn nicht beim API-Aufruf anfordern müssen, können Sie dies auch tun Verwenden Sie für die Authentifizierung dieselbe Methode wie für die Anmeldung. Das heißt, Sie können eine weitere Tabelle erstellen, um einen zufälligen Schlüssel / Salt für jede Client-App und eine hash_mac-Version des API-Geheimnisses zu speichern. Daher sind nur die API-ID und das API-Geheimnis erforderlich, um die API-Anforderung zu authentifizieren. Aber es ist mehr Arbeit.

Hinweis

Dies entspricht praktisch der Antwort von @Polynomial.

Auf diese Weise ist es für jemanden, der Ihren Server und Ihre Datenbank hackt, sehr, sehr schwierig, die Anmeldeinformationen Ihrer Benutzer zu stehlen und in ihrem Namen einen API-Anruf zu tätigen. Sie können jetzt beurteilen, ob eine Anforderung, die von einem API-Client angenommen wurde, der richtige Client oder deren Verlust ist.

Wenn der Benutzer sein Kennwort verliert, generieren Sie ein neues API-Geheimnis und einen neuen Schlüssel aus seinem neuen Kennwort neu .

Nun, in diesem Backend können Sie auch Server bereitstellen und trotzdem alle Daten lesen. Sie müssen sicherstellen, dass niemand auf Ihr Backend zugreifen kann, da er sonst alle Ihre Daten einschließlich Backups auf einmal liest.