|
|
|
| Делаю восстановление пароля и тут задумулся:
После того, как пользователь введет свой e-mail в форму, генерируется некий хэш, который сохряняется в базу и отправляется пользователю на почту.
И вот я думаю, что делать, если пользователь запросил восстановление еще раз (т.е. старый хэш еще не использован) - говорить, что восстановление пароля уже запрошено и надо пройти на почту, дабы пройти по сгенерированной ссылке, либо постоянно генерировать и обновлять хэш в базе. Что, по вашему, лучше? | |
|
|
|
|
|
|
|
для: neadekvat
(06.11.2010 в 20:45)
| | генерировать и обновлять - однозначно. - письмо может потеряться.
Другое дело, что не постоянно и мгновенно, а с некоторой паузой.
В час или день - вопрос отдельный.
Еще более правильно - отправлять на почту не пароль, а разовую ссылку, через которую можно зайти и пароль себе назначить.
в этом случае Вы, как владелец ресурса, не будете брать на себя ответственность даже косвенно.
Ответственность как за выбор пароля, так и за то, что он окажется на хранении в мэйлбоксе.
Если подходить к вопросу совсем параноидально, можно выставить запрашивающему пароль дополнительный разовый аутентифицирующий ключ в кукисе (независимо от ссылки), иа по ссылке проверить отклик этого ключа. | |
|
|
|
|
|
|
|
для: Trianon
(06.11.2010 в 20:50)
| | Спасибо за идею.
Так и сделаю: ссылка, отправленная на почту, будет вести на страницу установки нового пароля, а хэш и соответственно письмо будет по новой не ранее чем через полчаса отправляться. Запаздывание более 30-ти минут я не встречал (последнее время, тьфу-тьфу), а доступ к сервису будет являться достаточно критичным фактором, и заставлять ждать сутки - значит попращаться с клиентом. | |
|
|
|
|
|
|
|
для: neadekvat
(06.11.2010 в 20:57)
| | Я там дописал чуток.. успел в последнгюю секунду.. | |
|
|
|
|
|
|
|
для: Trianon
(06.11.2010 в 20:58)
| | Я и не заметил :)
Ну, я не настолько параноик, поэтому ограничусь описанным :) | |
|
|
|
|
|
|
|
для: neadekvat
(06.11.2010 в 21:01)
| | а зря, между прочим.
если из-за какой-то кривизны пользователю умудрятся подсунуть фишинг-страницу с кнопкой сброса пароля, то неизвестный перехватчику кукис поможет уберечься. | |
|
|
|
|
|
|
|
для: Trianon
(06.11.2010 в 21:04)
| | Хм. Но чем спасет кукис, если страница будет не моего сайта? | |
|
|
|
|
|
|
|
для: neadekvat
(06.11.2010 в 21:06)
| | А Вы уверены, что это будет страница с чужого сайта?
Пользователю могут запудрить мозги, подсунув ссылку (или фрейм) с Вашей же штатной страницей. | |
|
|
|
|
|
|
|
для: Trianon
(06.11.2010 в 21:12)
| | Хм, т.е. если на сайте google.com во фрейме откроется сайт yandex.ru, то для yandex.ru будут недоступны кукисы, установленные на его (yandex.ru) домене? | |
|
|
|
|
|
|
|
для: neadekvat
(06.11.2010 в 21:19)
| | Очевидно, будут доступны.
Но их не будет на компе того, кто контроль над е-мэйл перехватил, и по ссылке перейдет.
Если считать компьютеры запрашивающего (жертвы) и меняющего пароль (врага) разными. | |
|
|
|
|
|
|
|
для: neadekvat
(06.11.2010 в 20:57)
| | нет, я не имел в виду получасовой брейк на самом первом запросе. Зачем же мучать корректного пользователя?
Только на втором.
Более то этот интервал можно сделать нарастающим - 0 - 1 час - 2 часа - 4 часа - 8 часов и т.д. | |
|
|
|
|
|
|
|
для: Trianon
(06.11.2010 в 21:02)
| | То есть запрашивать ссылку можно без временных ограничений и пауз, а проходить по ссылке новой ссылке только через какое-то время, я правильно сейчас понял? | |
|
|
|
|
|
|
|
для: neadekvat
(06.11.2010 в 21:05)
| | скрипт, реагирующий на запрос сброса пароля добавляет запрос в таблицу заказов сброса (очевидно INSERT ... ON DUPLICATE KEY UPDATE ) и если строка уже есть - модифицирует время.
Если время должное (или пустое) - выставляет e-mail
Если нет - сообщает "не надо так часто - попробуйте через ... минут". | |
|
|
|
|
|
|
|
для: Trianon
(06.11.2010 в 21:10)
| | А, так. Мне кажется, мы недопоняли друг друга :)
Вы прочитали
"письмо будет не ранее чем через полчаса отправляться."
А у меня написано
"письмо будет по новой не ранее чем через полчаса отправляться."
А потом я подумал, что вы имеете в виду этапы восстановления (запрос, отправка хэша, проход по ссылке), а вы имели в виду итерации запроса хэша.
Так что все ясно :) | |
|
|
|
|
|
|
|
для: neadekvat
(06.11.2010 в 20:45)
| | имхо, второе. а вдруг первое письмо не дойдет, либо затеряется на почте, и пользователь захочет сгенерировать восстановление вновь. да и чуть-чуть проще для программиста | |
|
|
|
|
|
|
|
для: psychomc
(06.11.2010 в 20:55)
| | рассуждение "чуть чуть проще для программиста" когда речь идет о безопасности - тем более чужих данных - совершенно неуместно. | |
|
|
|
|
|
|
|
для: Trianon
(06.11.2010 в 20:57)
| | да, согласен. но если например оба варианта в плане безопасности были бы равносильными, то тогда, я думаю, это бы сыграло решающую роль | |
|
|
|
|
|
|
|
для: psychomc
(06.11.2010 в 20:55)
| | А что сложного в первом варианте? :)
<?php
$sql = "INSERT IGNORE...";
// запрос
if ( ! mysql_affected_rows()) {
$check->set_error('Вы уже запрашивали восстановление пароля.');
return false;
}
|
Вот я так и метался: вроде и письмо может затеряться, и чтобы по сто раз восстанавливали не хочется.. Использование обязательной паузы - лучший вариант, я думаю :) | |
|
|
|
|
|
|
|
для: neadekvat
(06.11.2010 в 21:03)
| | ну так да, одной дополнительной проверкой меньше :) | |
|
|
|