Kurz gesagt, nein. Mongo ObjectIds sind leicht zu erraten. Insbesondere unter hoher Last sind dies oft fortlaufende Nummern, da sich Zeitstempel, Maschinen- und Prozess-ID nicht ändern. Wenn Sie sich die Struktur von Objectid
ansehen , bestehen sie aus
a 4-byte timestamp,
a 3-byte machine identifier,
a 2-byte process id, and
a 3-byte counter, starting with a random value.
Daher haben sie sehr wenig Zufälligkeit. Ich sehe oft aufeinanderfolgende IDs in der Datenbank, zum Beispiel wenn eine Controller-Aktion ein Domänenobjekt schreibt, und einen Protokolleintrag in schneller Folge.
Wenn der Zeitstempel erraten werden kann und die Maschinen-ID bestimmbar ist (was der Fall ist, es sei denn, Sie haben einen riesigen Cluster), bleiben nur fünf Bytes übrig. Wenn ich mir eine Reihe generierter IDs ansehe, kann ich das wahrscheinlich auf etwa 50 Prozesse reduzieren, sodass die effektive Entropie irgendwo im 28-Bit-Bereich liegt. Das ist immer noch schwer zu erraten, aber für ein Zugriffstoken viel zu riskant.
Verwenden Sie stattdessen einen kryptografisch starken Pseudozufallszahlengenerator und erstellen Sie daraus ein Token. Beispielsweise in .NET der RNGCryptoServiceProvider ermöglicht das Erstellen von Zufallsdaten beliebiger Länge.
Als Nebenbemerkung schlage ich aus zwei Gründen vor, einen zusätzlichen kryptografischen Wrapper um Ihre OAuthTokens zu haben:
a) Sie möchten ungültige Token schnell feststellen können. Eine gültige kryptografische Shell kann immer noch ein ungültiges Token enthalten (eine widerrufene oder abgelaufene Erteilung), aber Sie müssen die Datenbank nicht jedes Mal bei Brute-Force-Angriffen treffen. Auch der Client
b) Clients können immer wieder Token anfordern. Obwohl dies nicht erforderlich ist, geben fast alle Systeme, die ich kenne, jedes Mal unterschiedliche Token zurück (egal, ob sie sich selbst validieren oder nicht). Normalerweise liegt das daran, dass der Token selbst eine begrenzte Gültigkeitsdauer hat. Das ist nicht die gleiche Gültigkeitsdauer, die die OAuth-Erteilung hat.
Was Sie wirklich in der Datenbank speichern möchten, ist die Berechtigung, d. h. die Erlaubnis, die ein Benutzer einem Client erteilt hat. Wenn diese Erteilung entfernt wird, werden alle Token ungültig. Das Einfügen jedes Mal eines neuen Tokens ist sehr unhandlich, da der Benutzer alle löschen müsste, um die Anwendungserlaubnis effektiv zu entfernen.
