Best Practices beim Generieren von OAuth-Token?

Question

Ich weiß, dass die OAuth spec nichts über den Ursprung der ConsumerKey, ConsumerSecret, AccessToken, RequestToken, TokenSecret oder Verifier-Code angibt, aber ich bin neugierig, ob es Best Practices zum Erstellen signifikant sicherer Token (insbesondere Token) gibt/Geheime Kombinationen).

Wie ich es sehe, gibt es ein paar Ansätze, um die Token zu erstellen:

1. Verwenden Sie einfach zufällige Bytes, Speichern in DB verbundenen Verbraucher/Nutzer
2. Hash einige Benutzer/verbraucherspezifischen Daten, Speicher in DB zu Verbraucher/Nutzer
3. Encrypt Benutzer/Verbraucher spezifische Daten zugeordnet

Vorteile (1) ist die Datenbank ist die einzige Quelle der Informationen, die die sicherste scheint. Es wäre schwieriger, einen Angriff gegen (2) oder (3) zu führen.

Das Hashing realer Daten (2) würde es ermöglichen, das Token aus vermutlich bereits bekannten Daten neu zu generieren. Könnte (1) wirklich keine Vorteile bieten, da sie sowieso gespeichert/gesucht werden müssten. Mehr CPU-intensiv als (1).

Durch das Verschlüsseln von echten Daten (3) kann die Entschlüsselung Informationen erkennen. Dies würde weniger Speicher benötigen & potenziell weniger Nachschlagewerke als (1) & (2), aber möglicherweise auch weniger sicher.

Gibt es andere Ansätze/Vorteile/Nachteile, die in Betracht gezogen werden sollten? Eine andere Überlegung ist, dass es irgendeine Art von Zufallswert in den Tokens geben muss, da es die Möglichkeit geben muss, neue Tokens ablaufen zu lassen und neu auszugeben, so dass es nicht nur aus echten Daten bestehen muss.

Folgen auf Fragen:

Gibt es eine Mindest Token Länge deutlich kryptographisch sicher zu machen? So wie ich es verstehe, würden längere Token Secrets sicherere Signaturen erstellen. Ist dieses Verständnis korrekt?

Gibt es Vorteile beim Verwenden einer bestimmten Codierung gegenüber einer anderen aus einer Hashing-Perspektive? Zum Beispiel sehe ich viele APIs mit Hex-Kodierungen (z. B. GUID-Strings). Im OAuth-Signaturalgorithmus wird das Token als Zeichenfolge verwendet. Bei einer Hex-Zeichenfolge wäre der verfügbare Zeichensatz viel kleiner (besser vorhersehbar) als bei einer Base64-Codierung. Es scheint mir, dass für zwei Strings gleicher Länge der mit dem größeren Zeichensatz eine bessere/breitere Hash-Verteilung hätte. Dies scheint mir, dass es die Sicherheit verbessern würde. Ist diese Annahme richtig?

Die OAuth-Spezifikation löst genau dieses Problem in 11.10 Entropy of Secrets.

Answer 1

OAuth sagt nichts über Token, außer dass ein Geheimnis damit verbunden ist. Also würden alle von dir erwähnten Schemata funktionieren. Unser Token entwickelte sich, als die Seiten größer wurden. Hier sind die Versionen, die wir vorher benutzt,

1. Unser erstes Token ist eine verschlüsselte BLOB mit Benutzername, Token-Geheimnis und Ablauf etc. Das Problem ist, dass wir nicht Token ohne Aufzeichnung 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 zur Datenbank verwendet wird. Es hat einen Benutzernamen Index, so dass es einfach ist, alle Token für einen Benutzer aufzulisten und zu widerrufen.

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

Einige Details der Implementierung, die Ihnen helfen können,

1. eine Version in dem Token hinzufügen, so dass Sie Token-Format, ohne zu brechen bestehende ändern können. All unser Token hat das erste Byte als Version.
2. Verwenden Sie eine URL-sichere Version von Base64, um das BLOB zu codieren, sodass Sie sich nicht mit den URL-Codierungsproblemen befassen müssen, was das Debugging mit OAuth-Signatur erschwert, da Sie möglicherweise triple-codierte Basestrings sehen.

Answer 2

Wie wäre es mit IP-Adresse in Token?

Dann könnten Sie bei jeder Anfrage Token entschlüsseln und Anfrage IP-Adresse mit Token IP-Adresse überprüfen.

Vielleicht wäre dieser Ansatz sicherer gegen zufällig generierte Angriffe.

Am besten!

Bearbeitet: Ok ich denke, vielleicht war ich nicht klar enaugh. Mein Beitrag war eine Frage, keine Antwort. Ich werde nicht versuchen, einen Artikel im Internet zu finden, wo ich die Implementierung mit IP-Adresse gelesen habe, und ich stimme zu, dass Clients mit dynamischen IP-Adressen und mobilen Verbindungen Token-Probleme haben werden, wenn Sie IP-Adressen in Token eingeben.