Sicheres Speichern eines Zugriffstokens

Question

Welche Sicherheitsmaßnahmen sollte ich ergreifen, um sicherzustellen, dass bei einer Gefährdung meiner Datenbank langlebige Zugriffstoken nicht gestohlen werden können?

Ein langlebiges Zugriffstoken ist so gut wie ein Benutzername und ein Passwort für einen bestimmten Dienst, aber aus Gesprächen mit anderen scheint es, dass die meisten (ich selbst eingeschlossen) Token im Klartext speichern. Dies scheint genauso schlimm zu sein wie das Speichern eines Passworts im Klartext. Offensichtlich kann man nicht das & Hash-Token salzen.

Idealerweise würde ich sie verschlüsseln wollen, aber ich bin mir nicht sicher, wie das am besten funktioniert, besonders bei einem Open-Source-Projekt.

Ich kann mir vorstellen, dass die Antwort auf diese Frage ähnlich ist wie bei der Speicherung von Zahlungsinformationen und PCI-Compliance, aber ich würde auch fragen, warum es keine weitere Diskussion darüber gibt? Vielleicht vermisse ich etwas.

Answer 1

Möchten Sie nur einen von anderen bereitgestellten Token verifizieren? Wenn ja, behandle es wie ein Passwort. Verwenden Sie einen Byteableitungsalgorithmus wie Password Based Key Derivation Function 2 (PBKDF2) (ebenfalls in RFC 2898 beschrieben) mit 10.000 Iterationen und speichern Sie die ersten 20 Bytes oder so. Wenn das Token empfangen wird. Es ist praktisch nicht reversibel.

Möchten Sie das Token zur Authentifizierung an andere weitergeben? Wenn dies der Fall ist, ist dies eine Herausforderung, denn wenn Ihre Anwendung den Token entschlüsseln oder anderweitig Zugriff darauf erhalten kann, kann dies auch für einen Angreifer der Fall sein. Denken Sie Shannons Maxim, der Angreifer kennt das System, besonders für ein Open-Source-Projekt. In diesem Fall besteht die beste Vorgehensweise darin, die Token mit einem starken Algorithmus zu verschlüsseln (z. B. AES256), Schlüssel mit einem starken kryptografischen Standard-Zufallszahlengenerator zu generieren und die Schlüssel sicher an einem anderen Ort als den Daten zu speichern B. in einer permission-geschützten Datei außerhalb der Datenbank im obigen Beispiel. Letzteres bedeutet, dass SQL-Injection-Angriffe die Schlüssel nicht aufdecken.