Рекомендации по созданию токенов OAuth?

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

Как я вижу, существует несколько подходов к созданию токенов:

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

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

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

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

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

EDIT: другое соображение состоит в том, что в токенах ДОЛЖНО быть какое-то случайное значение, поскольку должна существовать возможность истечения срока действия и переиздание новых токенов, поэтому он должен состоять не только из реальных данных.

Follow On Questions:

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

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

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

Ответ 1

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

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

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

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

Ответ 2

Как насчет ввода ip-адреса в токен?

Затем вы можете по каждому запросу дешифровать токен и проверить запрос ip-адрес с адресом токена ip.

Возможно, aproach будет более защищен от случайных сгенерированных атак.

Best!

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