Подскажите как безопасно реализовать сброс пароля на сайте. На текущий момент у меня работает так:

1. Пользователь запрашивает восстановление пароля
2. Отправляем ему письмо с рандомным токеном 
3. При переходе по ссылке проверяем токен и даем форму нового пароля
4. Хешруем пароль, сохраняем его в базу и авторируем пользователя.

Что можно улучшить\добавить ?

Обнуляем токен в базе, чтоб ссылка отработать могла только 1 раз
Выставить срок действия ссылки (24 часа, например)

Спасибо, а что будет если форму для ввода нового пароля откроет другой человек?

Он сможет сменить пароль если токен еще не был использован и срок жизни еще не истек.
Токен работает до того момента пока пользователь не сменил пароль или срок жизни его не прошел.
s0lman, вроде хорошо объяснил.

А что такое для сервера "другой человек"? Даже ваш компьютер не знает, что за ним сидите именно Вы...

Впрочем, вероятность угадать токен, на подобии "6GUI785dVBl0954fcHJNHFW690", по человеческим меркам равна нулю (для приведенного токена это 1 к 2.48*10^48).
Токен отправляется только на email владельца аккаунта. А за безопасность почтового ящика отвечаете уже не вы.

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

Допустим мы отправили ссылку с токеном на указанный email, а этот чеговек не стал менять пароль по этой ссылке, а передал ее 3 лицу, которое перешло по этой ссылке и поменяло пароль. Может есть смысл записывать какой-либо параметр в сессию того человека, который запросил восстановление пароля, а потом кроме токена еще и проверять установлен ли параметр?


Подскажите как правильно сгенерировать такой токен?


Это сообщение отредактировал(а) yngwie - 24.4.2013, 06:46

И что? А если кто-то поменяет пароль, а потом передаст свой логин и пароль третьему лицу? Это невозможно предупредить физически. 
Разве что пользователь подтверждал регистрацию с помощью паспортных данных у Вас в офисе, как, например, при регистрации банковской карты или персонального аттестата webMoney. Но ведь в вашем случае это не так...



Создать массив из цифр, маленьких и больших букв. Сделать array_rand 30 раз (или любой другой желаемой длины токена). Проверить. нет ли сейчас такого активного токена (созданного, но еще не использованного пользователем).

Спасибо, а еще такой вопрос. Допустим мы приняли какой-то токен для сброса пароля (когда пользователь переходит по ссылке из письма). Далее мы просто ищем такой токен в базе:



Этого достаточно или в WHERE нужно добавить какие-то еще условия?
P.S фильтрация пропущена для краткости.

yngwie Ситуации бывают разные.

•  юзер забыл пароль, у него есть почтовый ящик.
•  у юзера сломался напрочь почтовый ящик. Поможет привязка к телефону и sms, но это слишком сложно для большинства сайтов. Поможет служба "секретных ответов на вопросы", если юзер разрешил ее для себя. 
•  юзер передает свой аккаунт чужому человеку. В этом случае он отдает имя-пароль и другой человек меняет e-mail и пароль на свой. Для игрушечных сайтов и "корпоративных" аккаунтов на саппорт-сайтах - достаточно распространенная практика.

Для токенов разумнее завести отдельную таблицу. Так как каждый токен имеет

•  время жизни
•  привязку к пользователю
•  сопроводительную информация (кука, ip для параноиков).

Заводить отдельное поле для короткоживущих значений неразумно.

Время жизни токена пропущено.

Это почему? Сервисы смс-рассылок предоставляют нынче апи... Другое дело, сложно промотивировать пользователя ввести свой номер телефона   

Да потому что денег это стоит 1 рубль. Поэтому сложно для того если сайт не приносит прибыли.

У меня ситуация №1 (юзер забыл пароль, у него есть почтовый ящик)


Да прошу прощения. И все же, чтобы получить id пользователя для смены пароля мы ищем только токену и не истек ли он? Этого правда достаточно?


Это сообщение отредактировал(а) yngwie - 24.4.2013, 20:49

Обычно - да. Служба восстановления паролей по почте так и работает.

А вообще, частности могут всю малину попортить   Вот представь, что ты спрашиваешь на форуме - "как повесить картину на стене?"  и "правда ли что для этого нужен молоток и гвоздь". По идее - да, а в частности, если стены бетонные, то понадобится ударная дрель и нормальное сверло по бетону + дюбель. Если стена из особопрочного бетона - понадобится уже не дрель, а перфоратор. Если стены из гипрока - понадобится специальная фиговина, чтобы стену не своротить.

Получается, что если я узнаю чей-либо токен, то я смогу поменять этому человеку пароль? Мне кажется эир не очень безопасно.


Мне казалось, что существуют общие рекомендации для надежной смены пароля

Это сообщение отредактировал(а) yngwie - 25.4.2013, 11:21

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

Хоть вероятность этого крайне мала (<< 1 / 10^40 для токена из 30 символов), но теоретически кто-то может ввести токен "от балды" и попасть на страницу смены пароля. Но если такое случится, то второй раз в ближайшие миллион лет не случится точно =)))

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

Для утешения паранойи можете сделать связку логин+токен в отправляемой на email ссылке. Если логины не в открытом виде (логин не является именем пользователя), то угадать просто нереально.

Это сообщение отредактировал(а) Arantir - 25.4.2013, 12:03

Arantir К сожалению в качестве логина у меня используется email. А просить пользователя вводить email было бы глупо. Как считаете?

А я не предлагал просить пользователя вводить email. Я предлагал делать выборку из БД по двум значениям — логин+токен. Вы же не просите пользователя вводить токен, он передает по ссылке. Вот там же рядом еще логин приделать.
Ведь если ссылка содержит только токен, то кто-то может сесть и начать перебирать все возможные токены. Если пользователей на сайте очень много и одновременно существует очень много активных токенов, то хацкер может совершенно случайно угадать какой-то из них.
А если в ссылке еще и логин, то подобрать единственный возможный токен к какому-то логину уже просто нереально.

А имеет ли смысл записывать IP с которого был сделан запрос на восстановление пароля?

Записывать может и имеет, а вот проверять — нет. У огромнейшего числа пользователей IP динамические и/или "серые". Это значит не только то, что пока пользователь прочтет письмо, у него вполне IP может уже поменяться, но и то, что под одним и тем же IP может быть и 5, и 10, хоть 100 пользователей. Конечно, это не значит, что все они будут на вашем сайте, но факт остается фактом.

Зачастую IP, с которого поступил запрос восстановления, указывается пользователю в письме, чтобы тот сам оценил его значение для себя.

А что если в ссылке, по которой пользователь переходит из письма, добавлять еще email. Тогда можно проверять email в связке с токеном, только нсколько это безопасно?

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

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

Мое приложение работает по модели SAAS, будет очень не хорошо если кто-то получит доступ к чужим данным.

Если пользователи платят за это деньги, то, думаю, вы можете себе позволить, к примеру, упомянутые в этой теме СМС-подтверждения для разных важный действий (например, восстановления пароля).
В любом случае для обеспечения высокого уровня безопасности понадобятся средства. На надежный сервер, для защиты от ddos, для оплаты SSL-сертификата и всякое такое...

Ok. Спасибо Вам большое за помощь!