Стандарт HTTP-токена URL

Question

Мне нужно разработать функцию в системе, которая позволит незарегистрированным пользователям получать одноразовый доступ к системе через URL-токен, который генерируется / отправляется аутентифицированным пользователем.

Например, пользователь входит в систему и хочет поделиться информацией, поэтому система генерирует URL-адрес, например http://host/page?token=jkb345k4b5234k54kh5345kb34kb34.. Затем этот URL-адрес отправляется незарегистрированному пользователю, который будет следовать URL-адресу, чтобы получить ограниченный доступ. к нормально защищенным данным.

Первый вопрос - существуют ли какие-либо стандарты (RFC? IETF? Другие?), Которые будут определять генерацию URL? Единственные, что мне удалось найти, это RFC2289 и OpenToken , но ни один из них не имеет прямого отношения к тому, что мне нужно сделать, а последний находится только во втором состоянии черновика.

Существует еще одно соображение при проектировании: использовать ли односторонние крипто-хеш-функции и сохранять полезную нагрузку в локальном хранилище данных VS с использованием пар закрытого-открытого ключа и кодировать всю необходимую полезную нагрузку в самой уникальной строке.

В данный момент я сильно склоняюсь к одностороннему хэшированию, поскольку это дало бы мне гораздо большую свободу (без зависимости между размером полезной нагрузки и сгенерированной строкой) и меньше потенциальных проблем в будущем (например, что, если я решу добавить больше полезной нагрузки - как обеспечить обратную совместимость). И последнее, но не менее важное: случайное раскрытие закрытого ключа на стороне сервера потребует огромных усилий при регенерации ключа, обновлении всех живых экземпляров и т. Д. Ни одна из этих проблем не актуальна при выборе варианта одностороннего хеширования, но может быть, я что-то упускаю из виду? RFC2289 предпочитает одностороннюю криптографическую функцию, тогда как OpenToken выбирает параметр пары ключей.

И, наконец, кто-нибудь знает какую-либо библиотеку Java для их генерации?

Заранее спасибо.

Answer 1

Также взгляните на http://en.wikipedia.org/wiki/Universally_unique_identifier и RFC4122 . Внутри бэкэнда вам нужно будет прикрепить сгенерированный uuid к вашей сущности, чтобы проверка, основанная на UUID, могла быть проведена позже.

Кроме того, чаще всего токен может содержать некоторые данные (например, versioning + userdata), а затем используется надежный MD5-хеш для его «обфускации / анонимизации». Позже данные объединяются сервером и снова сравниваются хеш-значения.

Что касается java-lib и uuid, взгляните на UUID-javadoc .

Answer 2

Вот как бы я это сделал:

1. Создайте токен (вы можете использовать для этого UUID) и добавьте его в свою базу данных вместе со временем создания и с каким ресурсом токен должен предоставить доступ.на
2. Отправить электронное письмо пользователю с URL-адресом http://www.myserver.com/page?token=
3. Когда пользователь перейдет по URL-адресу, создайте новый сеанс с желаемым таймаутом и пометьте этот сеанс как авторизованный для просмотра любогов базе данных говорится, что пользователь должен видеть (если токен не слишком старый. Проверьте время создания по сравнению с текущим временем)
4. Либо удалите токен из базы данных, либо пометьте его как просроченный

Answer 3

Генерация случайных строк и сохранение их в базе данных с учетными данными.

Сгенерированные коды должны иметь два свойства: сложность и уникальность. Сложность гарантирует, что их невозможно угадать, а уникальность гарантирует, что один и тот же код никогда не будет сгенерирован дважды. Помимо этого, конкретный метод не имеет значения.

Создайте строки токенов с двумя частями. Первая часть зависит от времени, где ключ будет увеличиваться и изменяться предсказуемым образом с каждой миллисекундой. Вторая часть полностью случайна. В сочетании это даст вам уникальную и сложную длинную строку.

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

Когда пользователь нажимает на ссылку с токеном, пометьте этот токен как используемый в базе данных. Еще лучше установить временную метку для использования, чтобы срок ее действия истек, возможно, через 24 часа после первого щелчка. Такой подход дает вам гибкость для реализации этой конкретной части требования, необходимой для вашего проекта.

Ранее я использовал это решение во многих различных случаях не только для одноразового доступа к системе, но и для кодов доступа к билетам, кодов подарочных сертификатов и всего, что является одноразовым. Не имеет значения, что вы используете для генерации токена, насколько вы можете гарантировать его сложность и уникальность.

Answer 4

Токен нужен только тогда, когда пользователь делится одним фрагментом информации.Итак, вы не можете просто сгенерировать случайный токен и связать его с частью информации (например, с полем базы данных)?Это намного проще, чем делать какие-либо криптовалюты ...