Zkrátka ne. Mongo ObjectIds lze snadno uhodnout. Zejména při vysokém zatížení jsou to často po sobě jdoucí čísla, protože časové razítko, stroj a ID procesu se nemění. Pokud se podíváte na strukturu Objectid
, jsou složeny z
a 4-byte timestamp,
a 3-byte machine identifier,
a 2-byte process id, and
a 3-byte counter, starting with a random value.
Proto mají velmi malou náhodnost. V databázi často vidím po sobě jdoucí ID, například když nějaká akce řadiče zapíše objekt domény a záznam protokolu v rychlém sledu.
Pokud lze časové razítko uhodnout a ID počítače je určitelné (což je, pokud nemáte velký cluster), zbývá pouze pět bajtů. Když se podívám na řadu generovaných ID, pravděpodobně to mohu snížit na 50 procesů, takže efektivní entropie je někde v rozsahu 28 bitů. To je stále těžké odhadnout, ale pro přístupový token je to příliš riskantní.
Místo toho použijte kryptograficky silný generátor pseudonáhodných čísel a vytvořte z něj token. Například v .NET, RNGCryptoServiceProvider umožňuje vytvářet náhodná data libovolné délky.
Jako vedlejší poznámku navrhuji mít kolem vašich OAuthTokenů další kryptografický obal, a to ze dvou důvodů:
a) Chcete být schopni rychle určit neplatné tokeny. Platný kryptografický shell může stále obsahovat neplatný token (zrušený nebo vypršelý grant), ale nemusíte pokaždé zasáhnout databázi útoky hrubou silou. Také klient
b) Klienti mohou žádat o tokeny znovu a znovu. I když to není požadavek, téměř všechny systémy, které znám, vracejí pokaždé jiné tokeny (bez ohledu na to, zda se ověřují nebo ne). Obvykle je to proto, že samotný token má omezenou dobu platnosti. To není stejná doba platnosti, jakou má udělení OAuth.
V databázi skutečně chcete uložit grant, tedy oprávnění, které dal nějaký uživatel nějakému klientovi. Pokud je tento grant odebrán, všechny tokeny se stanou neplatnými. Pokaždé vložit nový token je velmi nepraktické, protože uživatel by je musel všechny smazat, aby bylo možné účinně odstranit udělení žádosti.