Задать вопрос

Задачка о шифровании

Этот вопрос является продолжением вопроса о форме восстановления пароля на сайте.

Приведу его полностью

Сделали формочку с полем для ввода почты и кнопкой «Восстановить пароль».

При нажатии на нее на почту (если такая есть в базе) отправляется ссылка вида
site.ru/fastlogin/name@mail.ru/823497378934270324789543

По ссылке мы определяем совпадает ли почта и хеш пароля (823497378934270324789543) с данными учетки. Если да, то человек автоматически входит на сайт. То есть перешел по ссылке и уже залогинен.

Вроде бы все очень легко и удобно. Но чувствуется что тут есть какие-то подводные камни. Может быть вы увидите их? 

Главным недочетом, предложенного мною ранее варианта, является то, что этот хеш делается, грубо говоря, так

md5($pass.$salt);

и, соответственно, хеш не меняется до тех пор, пока пользователь не сменит пароль.

Самое главное тут, (спасибо отозвавшимся и ++ конечно :), придать таким ссылкам срок годности, скажем, в один час.

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

Собственно вопрос.
Можно ли в хеше предусмотреть возможность внедрения срока годности?
Если да, хотелось бы увидеть алгоритм, ну или хотя-бы понять в каком направлении двигаться.

Пока что в голову приходит только вариант с обратимым шифрованием Mcrypt, но пока что не удается добиться его правильной работы. Проблему описал в этом вопросе habrahabr.ru/qa/25015/
  • Вопрос задан
  • 3359 просмотров
Подписаться 3 Оценить Комментировать
Пригласить эксперта
Ответы на вопрос 2
Urvin
@Urvin
например, код можно формировать как-то так:
HEX(симметричный_шифр(array(сложный_хэш_пароля, дата_окончания_хеша, сложный_хеш_включающий_дату_и_хэш_пароля)))
Загляните на phpclasses, там есть готовые алгоритмы в обход mcrypt.
Дополнительно нужно учесть лимит get-запроса.

Есть лучше вариант: например, можно давать срок на три дня, код записывать как
md5($password . $salt . date('Y-m-d', strtotime('+3 days')))
после перехода клиента по ссылке проверять соответствие пришедшего кода коду, сгенерированному на следующие три дня.
Минусы, думаю, понятны.

Отбрасывая вариант сохранения в бд Вы лишаетесь возможности контролировать количество переходов по приведенной ссылке, плюс приходится формировать довольно сложный url.
Ответ написан
Комментировать
Wott
@Wott
Я предпочитаю не отдавать вообще ничего, что можно восстановить до пароля.
В похожем случае я делал случайные наборы типа sha1(random()) они падали в отдельную табличку где ключ — то самое случайное число, а также — ссылка на пользователя, дата и прочие плюшки, типа страницы редиректа. permalink роутил входящие ссылки, проверял их, показывал форму изменения пароля и перенаправлял на нужную страницу, уже под данным пользователем
Ответ написан
Комментировать
Ваш ответ на вопрос

Войдите, чтобы написать ответ

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