Кращі практики щодо створення токенів OAuth?

Я розумію, що специфікація OAuth нічого не вказує про походження коду ConsumerKey, ConsumerSecret, AccessToken, RequestToken, TokenSecret або Verifier, але мені цікаво, чи є найкращі практики створення значно захищених жетонів (особливо Token / Таємні комбінації).

Як я бачу, існує декілька підходів до створення жетонів:

1. Просто використовуйте випадкові байти, зберігайте в БД, пов’язаних зі споживачем / користувачем
2. Хешіть деякі дані, що стосуються користувача / споживача, зберігайте в БД, пов’язаних зі споживачем / користувачем
3. Шифруйте дані, що стосуються користувача / споживача

Переваги до (1) - це база даних є єдиним джерелом інформації, яка видається найбільш захищеною. Було б важче запустити атаку проти, ніж (2) або (3).

Хешування реальних даних (2) дозволить повторно генерувати маркер з імовірно вже відомих даних. Можливо, насправді не надавати жодних переваг (1), оскільки все одно потрібно зберігати / шукати. Більш інтенсивний процесор, ніж (1).

Шифрування реальних даних (3) дозволило б розшифрувати інформацію. Це вимагатиме менше сховища та потенційно меншої кількості пошукових запитів, ніж (1) та (2), але також може бути менш безпечним.

Чи є інші підходи / переваги / недоліки, які слід враховувати?

EDIT: ще одна думка полягає в тому, що В Токенах ОБОВ'ЯЗКОВО має бути якесь випадкове значення, оскільки повинно існувати можливість закінчення терміну дії та повторного випуску нових токенів, тому воно не повинно складатися лише з реальних даних.

Дотримуйтесь питань :

Чи є мінімальна довжина токена, щоб зробити істотно криптографічно захищеним? Як я розумію, довші Token Secrets створюватимуть більш безпечні підписи. Чи правильно це розуміння?

Чи є переваги використання певного кодування над іншим з точки зору хешування? Наприклад, я бачу багато API, які використовують шістнадцяткові кодування (наприклад, рядки GUID). В алгоритмі підпису OAuth Token використовується як рядок. З шістнадцятковим рядком доступний набір символів був би набагато меншим (передбачуванішим), ніж скажімо, з кодуванням Base64. Мені здається, що для двох рядків однакової довжини одна з більшим набором символів мала б краще / ширше хеш-розподіл. Мені здається, це покращило б безпеку. Чи правильне це припущення?

Специфікація OAuth порушує цю проблему в 11.10 "Ентропія секретів" .

OAuth нічого не говорить про маркер, крім того, що в ній є секрет. Так усі схеми, про які ви згадали, спрацювали б. Наш жетон розвивався в міру збільшення сайтів. Ось версії, які ми використовували раніше,

1. Наш перший маркер - це зашифрований BLOB з ім'ям користувача, секретом маркера та терміном дії, і т.д.

2. Тож ми змінили його для зберігання всього в базі даних, а маркер - це просто випадкове число, яке використовується як ключ до бази даних. Він має індекс імені користувача, тому легко перерахувати всі маркери для користувача та відкликати його.

3. Ми отримуємо досить мало хакерських дій. З випадковим числом нам потрібно перейти до бази даних, щоб знати, чи маркер дійсний. Тому ми знову повернулися до шифрованого BLOB. Цього разу маркер містить лише зашифроване значення ключа та термін дії. Таким чином ми можемо виявити недійсні або терміни, що втратили чинність, не переходячи до бази даних.

Деякі деталі реалізації, які можуть допомогти вам,

1. Додайте версію в маркер, щоб ви могли змінити формат жетону, не порушуючи існуючих. Весь наш маркер має перший байт як версію.
2. Використовуйте безпечну для Base64 URL-версію для кодування BLOB, щоб вам не довелося мати справу з проблемами кодування URL-адрес, що ускладнює налагодження з підписом OAuth, тому що ви можете побачити потрійну закодовану базову рядок.