Best Practices zum Generieren von OAuth-Token?

Mir ist klar, dass die OAuth- Spezifikation nichts über die Herkunft des ConsumerKey-, ConsumerSecret-, AccessToken-, RequestToken-, TokenSecret- oder Verifier-Codes angibt, aber ich bin gespannt, ob es bewährte Methoden zum Erstellen signifikant sicherer Token gibt (insbesondere Token / Geheime Kombinationen).

Aus meiner Sicht gibt es einige Ansätze zum Erstellen der Token:

1. Verwenden Sie einfach zufällige Bytes und speichern Sie sie in der Datenbank, die dem Verbraucher / Benutzer zugeordnet ist
2. Hash einige benutzer- / verbraucherspezifische Daten, die in der mit Verbraucher / Benutzer verknüpften Datenbank gespeichert sind
3. Benutzer- / verbraucherspezifische Daten verschlüsseln

Vorteile von (1) sind, dass die Datenbank die einzige Informationsquelle ist, die am sichersten erscheint. Es wäre schwieriger, einen Angriff auszuführen als (2) oder (3).

Das Hashing von realen Daten (2) würde es ermöglichen, das Token aus vermutlich bereits bekannten Daten neu zu generieren. Könnte (1) keine wirklichen Vorteile bieten, da es sowieso gespeichert / nachgeschlagen werden müsste. CPU-intensiver als (1).

Das Verschlüsseln realer Daten (3) würde das Entschlüsseln ermöglichen, um Informationen zu kennen. Dies würde weniger Speicherplatz und möglicherweise weniger Suchvorgänge als (1) und (2) erfordern, aber möglicherweise auch weniger sicher.

Gibt es andere Ansätze / Vor- / Nachteile, die berücksichtigt werden sollten?

BEARBEITEN: Eine weitere Überlegung ist, dass die Token einen zufälligen Wert enthalten MÜSSEN, da die Möglichkeit vorhanden sein muss, neue Token abzulaufen und erneut auszugeben, damit sie nicht nur aus realen Daten bestehen dürfen.

Folgen Sie den Fragen :

Gibt es eine Mindestlänge für Token, um eine kryptografisch signifikante Sicherheit zu gewährleisten? Soweit ich weiß, würden längere Token-Geheimnisse sicherere Signaturen erzeugen. Ist dieses Verständnis richtig?

Gibt es aus Hashing-Sicht Vorteile bei der Verwendung einer bestimmten Codierung gegenüber einer anderen? Zum Beispiel sehe ich viele APIs, die Hex-Codierungen verwenden (z. B. GUID-Zeichenfolgen). Im OAuth-Signaturalgorithmus wird das Token als Zeichenfolge verwendet. Mit einer Hex-Zeichenfolge wäre der verfügbare Zeichensatz viel kleiner (vorhersehbarer) als beispielsweise mit einer Base64-Codierung. Es scheint mir, dass für zwei gleich lange Zeichenfolgen die mit dem größeren Zeichensatz eine bessere / breitere Hash-Verteilung haben würde. Dies scheint mir, dass es die Sicherheit verbessern würde. Ist diese Annahme richtig?

Die OAuth-Spezifikation wirft genau dieses Problem in 11.10 Entropy of Secrets auf .

OAuth sagt nichts über Token aus, außer dass ihm ein Geheimnis zugeordnet ist. Alle von Ihnen erwähnten Schemata würden also funktionieren. Unser Token hat sich weiterentwickelt, als die Websites größer wurden. Hier sind die Versionen, die wir zuvor verwendet haben:

1. Unser erstes Token ist ein verschlüsseltes BLOB mit Benutzername, Token-Geheimnis und Ablauf usw. Das Problem ist, dass wir Token nicht ohne Datensatz auf dem Host widerrufen können.

2. Also haben wir es geändert, um alles in der Datenbank zu speichern, und das Token ist einfach eine Zufallszahl, die als Schlüssel für die Datenbank verwendet wird. Es hat einen Benutzernamenindex, so dass es einfach ist, alle Token für einen Benutzer aufzulisten und zu widerrufen.

3. Wir bekommen ziemlich wenige Hacking-Aktivitäten. Mit einer Zufallszahl müssen wir zur Datenbank gehen, um zu wissen, ob das Token gültig ist. Also gingen wir wieder zu verschlüsseltem BLOB zurück. Dieses Mal enthält das Token nur den verschlüsselten Wert des Schlüssels und des Ablaufs. So können wir ungültige oder abgelaufene Token erkennen, ohne in die Datenbank zu gehen.

Einige Implementierungsdetails, die Ihnen helfen können,

1. Fügen Sie dem Token eine Version hinzu, damit Sie das Token-Format ändern können, ohne vorhandene zu beschädigen. Alle unsere Token haben das erste Byte als Version.
2. Verwenden Sie die URL-sichere Version von Base64, um das BLOB zu codieren, damit Sie sich nicht mit den Problemen der URL-Codierung befassen müssen. Dies erschwert das Debuggen mit der OAuth-Signatur, da möglicherweise dreifach codierte Basiszeichen angezeigt werden.