Накратко, не. Mongo ObjectIds са лесни за отгатване. По-специално, при голямо натоварване, това често са последователни числа, тъй като клеймото за време, идентификаторът на машината и процеса не се променят. Ако погледнете структурата на Objectid
, те се състоят от
a 4-byte timestamp,
a 3-byte machine identifier,
a 2-byte process id, and
a 3-byte counter, starting with a random value.
Следователно те имат много малка случайност. Често виждам последователни идентификатори в базата данни, например ако някое действие на контролера запише обект на домейн и запис в журнала в бърза последователност.
Ако клеймото може да се познае и идентификаторът на машината може да се определи (което е, освен ако нямате огромен клъстер), остават само пет байта. Като гледам редица генерирани идентификатори, вероятно мога да ги намаля до около 50 процеса, така че ефективната ентропия да е някъде в 28-битовия диапазон. Това все още е трудно да се отгатне, но е твърде рисковано за токен за достъп.
Вместо това използвайте криптографски силен генератор на псевдослучайни числа и създайте токен от него. Например в .NET, RNGCryptoServiceProvider позволява създаване на произволни данни с произволна дължина.
Като странична бележка предлагам да имате допълнителна криптографска обвивка около вашите OAuthTokens по две причини:
а) Искате да можете бързо да определяте невалидни токени. Една валидна криптографска обвивка все още може да включва невалиден токен (отменено или изтекло разрешение), но не е нужно да натискате базата данни при атаки с груба сила всеки път. Освен това клиентът
б) Клиентите могат да изискват токени отново и отново. Въпреки че не е изискване, почти всички системи, които познавам, връщат различни токени всеки път (без значение дали са самовалидиращи се или не). Обикновено това е така, защото самият токен има ограничен период на валидност. Това не е същият период на валидност, който има разрешението за OAuth.
В базата данни това, което наистина искате да съхраните, е разрешението, т.е. разрешението, дадено от даден потребител на даден клиент. Ако това разрешение бъде премахнато, всички токени стават невалидни. Вмъкването на нов токен всеки път е много неудобно, защото потребителят ще трябва да ги изтрие всички, за да премахне ефективно разрешението за приложение.
