Лучшие практики по созданию OAuth-токенов?

Question

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

На мой взгляд, существует несколько подходов к созданию токенов:

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

Преимущества (1) в том, что база данных является единственным источником информации, который представляется наиболее безопасным. Было бы сложнее провести атаку против (2) или (3).

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

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

Существуют ли другие подходы / преимущества / недостатки, которые следует учитывать?

РЕДАКТИРОВАТЬ: еще одно соображение заключается в том, что в токенах ДОЛЖНА быть какая-то случайная величина, поскольку должна существовать возможность истечения срока действия и переиздания новых токенов, поэтому она не должна состоять только из реальных данных.

Следите за вопросами :

Существует ли минимальная длина токена для обеспечения криптографической безопасности? Насколько я понимаю, более длинные секреты токенов создавали бы более безопасные подписи. Это понимание правильно?

Есть ли преимущества использования определенной кодировки перед другой с точки зрения хеширования? Например, я вижу много API, использующих шестнадцатеричные кодировки (например, строки GUID). В алгоритме подписи OAuth токен используется в качестве строки. С шестнадцатеричной строкой доступный набор символов будет намного меньше (более предсказуемым), чем, скажем, с кодировкой Base64. Мне кажется, что для двух строк одинаковой длины, строка с большим набором символов будет иметь лучшее / более широкое распределение хеша. Мне кажется, что это улучшит безопасность. Это предположение верно?

Спецификация OAuth поднимает эту проблему в 11.10 Энтропия секретов .

Answer 1

OAuth ничего не говорит о токене, за исключением того, что с ним связан секрет. Таким образом, все схемы, которые вы упомянули, будут работать. Наш токен развивался по мере увеличения сайтов. Вот версии, которые мы использовали раньше,

1. Наш первый токен - это зашифрованный BLOB с именем пользователя, секретом токена, сроком действия и т. Д. Проблема в том, что мы не можем отозвать токены без записи на хосте.

2. Итак, мы изменили его, чтобы хранить все в базе данных, а токен - это просто случайное число, используемое в качестве ключа к базе данных. Он имеет индекс имени пользователя, поэтому легко перечислить все токены для пользователя и отозвать его.

3. У нас довольно мало хакерских действий. При случайном числе мы должны перейти в базу данных, чтобы узнать, является ли токен действительным. Итак, мы снова вернулись к зашифрованному BLOB. На этот раз токен содержит только зашифрованное значение ключа и срок его действия. Таким образом, мы можем обнаружить недействительные или просроченные токены, не заходя в базу данных.

Некоторые детали реализации, которые могут вам помочь,

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

Answer 2

Как насчет помещения ip адреса в токен?

Затем вы можете при каждом запросе расшифровывать токен и проверять IP-адрес запроса с помощью IP-адреса токена.

Возможно, этот подход был бы более защищен от случайных атак.

Best!

Отредактировано: Хорошо, я думаю, может быть, я не был ясен, смеяться. Мой пост был вопросом, а не ответом. Я не буду пытаться найти статью в Интернете, где я читаю реализацию с IP-адресом, и я согласен, что если вы поместите IP-адрес в токен, у клиентов с динамическими IP-адресами и мобильными соединениями будут проблемы с токеном.