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

Я понимаю, что в спецификации 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 Энтропии секретов .

93 голоса | спросил mckamey 26 +03002009-10-26T21:41:26+03:00312009bEurope/MoscowMon, 26 Oct 2009 21:41:26 +0300 2009, 21:41:26

2 ответа


0

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

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

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

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

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

  1. Добавьте версию в токен, чтобы вы могли изменить формат токена, не нарушая существующие. Весь наш токен имеет первый байт в качестве версии.
  2. Используйте URL-безопасную версию Base64 для кодирования BLOB, чтобы вам не приходилось сталкиваться с проблемами кодирования URL, что затрудняет отладку с помощью подписи OAuth, поскольку вы можете увидеть тройную закодированную базовую строку.
ответил ZZ Coder 26 +03002009-10-26T22:45:37+03:00312009bEurope/MoscowMon, 26 Oct 2009 22:45:37 +0300 2009, 22:45:37
0

А как насчет размещения IP-адреса в токене?

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

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

Best!

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

ответил Dean Barisic 6 MaramSun, 06 Mar 2016 11:50:50 +03002016-03-06T11:50:50+03:0011 2016, 11:50:50

Похожие вопросы

Популярные теги

security × 330linux × 316macos × 2827 × 268performance × 244command-line × 241sql-server × 235joomla-3.x × 222java × 189c++ × 186windows × 180cisco × 168bash × 158c# × 142gmail × 139arduino-uno × 139javascript × 134ssh × 133seo × 132mysql × 132