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

Вот мой сценарий...

  1. Клиентское приложение пользователя отправляет запрос на доступ к веб-службе.

  2. Веб-сервис отвечает «ключом», который действителен только в течение X секунд/минут (время может быть переменным или, по крайней мере, определяемым в моем веб-сервисе).

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

  4. Веб-служба проверяет, что ключ все еще действителен, и если он обрабатывает запрос, в противном случае отвечает соответствующим образом.

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

Я думаю, что я действительно спрашиваю, как лучше всего это сделать.

Язык: VB.Net


authentication .net passwords security one-time-password
person Hades    schedule 03.04.2011    source источник

Ответы (3)


arrow_upward
1
arrow_downward

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

person Femaref    schedule 03.04.2011
comment
Это неправильно. Если я знаю соль, то хеш, основанный на времени (количество минут с 01.01.1970) через 2 минуты в будущем, позволит мне проверить достоверность и дать хешу срок жизни 2 минуты. Мне интересно, это лучший способ сделать это или есть лучший способ, который также не требует хранения хэша в базе данных. - person Hades; 04.04.2011
comment
Вы используете систему передачи без сохранения состояния с HTTP. Невозможно сохранить хэш каким-либо образом или в какой-либо форме, и база данных — лучший способ для этого. - person Femaref; 04.04.2011
comment
@Femaref Я согласен, что вам нужно хранить некоторую информацию. Но вы не можете использовать только шифрование для аутентификации личности. Одним из решений в этом случае может быть одноразовый пароль. - person yadab; 11.02.2012

arrow_upward
0
arrow_downward

мы использовали сторонний инструмент для этого. Называется Крипкей. Очень настраиваемый, но не дешевый.

person Dan    schedule 03.04.2011
comment
Спасибо, но мы не создаем ключ продукта. В нашей системе есть как клиенты, так и реселлеры. Я пытаюсь создать систему API, которая позволила бы торговому посреднику получить ключ, который он затем может передать по URL-адресу для входа в качестве своей учетной записи торгового посредника в любую из областей администрирования своего клиента. - person Hades; 04.04.2011

arrow_upward
0
arrow_downward

В итоге остановились на следующем....

Соль, известная приложению Имя пользователя пользователя Текущая дата/время + 5 секунд

объедините вышеперечисленное в определенном порядке в виде строки и хешируйте ее MD5.

У нас есть специальный URL-адрес, который они могут использовать с хешем в качестве параметра строки запроса.

Сравниваем хеш с 5 хешами, сгенерированными на момент запроса (по одному за текущую секунду и по одному за каждую из предыдущих 4 секунд). Если хэш параметра QS совпадает с одним из этих 5 сгенерированных хэшей, мы принимаем запрос и выполняем соответствующие действия.

У нас есть метод в нашем API, который возвращает URL-адрес с уже примененным хешем. После этого клиенты API могут немедленно отправить свой запрос на предоставленный URL-адрес. Любые запросы, сделанные более чем через 5 секунд после получения URL-адреса, отклоняются.

Итак, у нас есть ключ, который действителен только в течение 5 секунд с момента его генерации.

Это позволяет нам предоставлять пользователям возможность «автоматического входа» на свой сайт из клиента API. Клиент запрашивает URL-адрес для входа (который поставляется с хэшем), а затем сразу же направляет веб-браузер пользователей на этот URL-адрес. URL-адрес обрабатывает запрос, проверяет хэш и, если он действителен, устанавливает файл cookie для входа и перенаправляет их на свою страницу администратора.

Просто, эффективно и, поскольку все наши API-запросы проходят через SSL, безопасно.

person Hades    schedule 11.02.2012
comment
не будет ли он подвержен перехвату сеанса? - person yadab; 11.02.2012
comment
Как? Любой, кто попытается взломать его, должен будет знать соль и обычные учетные данные пользователя, чтобы сгенерировать ключ. Поскольку веб-служба, используемая для извлечения ключа, и URL-адреса, на которых используется ключ, защищены SSL, они должны быть достаточно безопасными. - person Hades; 12.02.2012
comment
каковы нормальные учетные данные? - person yadab; 13.02.2012
comment
Данные для входа пользователей. Что-то вроде Username+PasswordHash+Salt+ExpiryTimestamp - person Hades; 14.02.2012
comment
Извините, возможно, я неправильно понял ваш вопрос. Таким образом, ваше приложение имеет доступ к базе данных учетных данных пользователей во время проверки. Это означает, что вы выполняете обычную аутентификацию. что нормально. Аутентификация в обычной форме принимает только имя пользователя и пароль и отправляет через https после того, как сервер проверяет имеющиеся у него учетные данные. en.wikipedia.org/wiki/HTTP%2BHTML_form-based_authentication . Но эта форма аутентификации подвержена фишингу, но это нормально, поскольку она используется везде. - person yadab; 15.02.2012
comment
На самом деле нет, если человек, занимающийся фишингом, не знает соли, порядка, в котором мы объединяем различные части, и алгоритма хеширования, который мы используем. - person Hades; 22.02.2012