Форум: Форум PHPФорум ApacheФорум Регулярные ВыраженияФорум MySQLHTML+CSS+JavaScriptФорум FlashРазное
Новые темы: 0000000
PHP 5. На примерах. Авторы: Кузнецов М.В., Симдянов И.В., Голышев С.В. PHP Puzzles. Авторы: Кузнецов М.В., Симдянов И.В. PHP. Практика создания Web-сайтов (второе издание). Авторы: Кузнецов М.В., Симдянов И.В. MySQL 5. В подлиннике. Авторы: Кузнецов М.В., Симдянов И.В. Самоучитель MySQL 5. Авторы: Кузнецов М.В., Симдянов И.В.
ВСЕ НАШИ КНИГИ
Консультационный центр SoftTime

Разное

Выбрать другой форум

 

Здравствуйте, Посетитель!

вид форума:
Линейный форум Структурный форум

тема: Восстановление пароля
 
 автор: neadekvat   (06.11.2010 в 20:45)   письмо автору
 
 

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

  Ответить  
 
 автор: Trianon   (06.11.2010 в 20:50)   письмо автору
 
   для: neadekvat   (06.11.2010 в 20:45)
 

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

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

  Ответить  
 
 автор: neadekvat   (06.11.2010 в 20:57)   письмо автору
 
   для: Trianon   (06.11.2010 в 20:50)
 

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

  Ответить  
 
 автор: Trianon   (06.11.2010 в 20:58)   письмо автору
 
   для: neadekvat   (06.11.2010 в 20:57)
 

Я там дописал чуток.. успел в последнгюю секунду..

  Ответить  
 
 автор: neadekvat   (06.11.2010 в 21:01)   письмо автору
 
   для: Trianon   (06.11.2010 в 20:58)
 

Я и не заметил :)
Ну, я не настолько параноик, поэтому ограничусь описанным :)

  Ответить  
 
 автор: Trianon   (06.11.2010 в 21:04)   письмо автору
 
   для: neadekvat   (06.11.2010 в 21:01)
 

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

  Ответить  
 
 автор: neadekvat   (06.11.2010 в 21:06)   письмо автору
 
   для: Trianon   (06.11.2010 в 21:04)
 

Хм. Но чем спасет кукис, если страница будет не моего сайта?

  Ответить  
 
 автор: Trianon   (06.11.2010 в 21:12)   письмо автору
 
   для: neadekvat   (06.11.2010 в 21:06)
 

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

  Ответить  
 
 автор: neadekvat   (06.11.2010 в 21:19)   письмо автору
 
   для: Trianon   (06.11.2010 в 21:12)
 

Хм, т.е. если на сайте google.com во фрейме откроется сайт yandex.ru, то для yandex.ru будут недоступны кукисы, установленные на его (yandex.ru) домене?

  Ответить  
 
 автор: Trianon   (06.11.2010 в 21:40)   письмо автору
 
   для: neadekvat   (06.11.2010 в 21:19)
 

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

  Ответить  
 
 автор: Trianon   (06.11.2010 в 21:02)   письмо автору
 
   для: neadekvat   (06.11.2010 в 20:57)
 

нет, я не имел в виду получасовой брейк на самом первом запросе. Зачем же мучать корректного пользователя?
Только на втором.
Более то этот интервал можно сделать нарастающим - 0 - 1 час - 2 часа - 4 часа - 8 часов и т.д.

  Ответить  
 
 автор: neadekvat   (06.11.2010 в 21:05)   письмо автору
 
   для: Trianon   (06.11.2010 в 21:02)
 

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

  Ответить  
 
 автор: Trianon   (06.11.2010 в 21:10)   письмо автору
 
   для: neadekvat   (06.11.2010 в 21:05)
 

скрипт, реагирующий на запрос сброса пароля добавляет запрос в таблицу заказов сброса (очевидно INSERT ... ON DUPLICATE KEY UPDATE ) и если строка уже есть - модифицирует время.
Если время должное (или пустое) - выставляет e-mail
Если нет - сообщает "не надо так часто - попробуйте через ... минут".

  Ответить  
 
 автор: neadekvat   (06.11.2010 в 21:16)   письмо автору
 
   для: Trianon   (06.11.2010 в 21:10)
 

А, так. Мне кажется, мы недопоняли друг друга :)
Вы прочитали
"письмо будет не ранее чем через полчаса отправляться."
А у меня написано
"письмо будет по новой не ранее чем через полчаса отправляться."

А потом я подумал, что вы имеете в виду этапы восстановления (запрос, отправка хэша, проход по ссылке), а вы имели в виду итерации запроса хэша.

Так что все ясно :)

  Ответить  
 
 автор: psychomc   (06.11.2010 в 20:55)   письмо автору
 
   для: neadekvat   (06.11.2010 в 20:45)
 

имхо, второе. а вдруг первое письмо не дойдет, либо затеряется на почте, и пользователь захочет сгенерировать восстановление вновь. да и чуть-чуть проще для программиста

  Ответить  
 
 автор: Trianon   (06.11.2010 в 20:57)   письмо автору
 
   для: psychomc   (06.11.2010 в 20:55)
 

рассуждение "чуть чуть проще для программиста" когда речь идет о безопасности - тем более чужих данных - совершенно неуместно.

  Ответить  
 
 автор: psychomc   (06.11.2010 в 21:07)   письмо автору
 
   для: Trianon   (06.11.2010 в 20:57)
 

да, согласен. но если например оба варианта в плане безопасности были бы равносильными, то тогда, я думаю, это бы сыграло решающую роль

  Ответить  
 
 автор: neadekvat   (06.11.2010 в 21:03)   письмо автору
 
   для: psychomc   (06.11.2010 в 20:55)
 

А что сложного в первом варианте? :)
<?php
$sql 
"INSERT IGNORE...";
// запрос

if ( ! mysql_affected_rows()) {
    
$check->set_error('Вы уже запрашивали восстановление пароля.');
     return 
false;
}


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

  Ответить  
 
 автор: psychomc   (06.11.2010 в 21:08)   письмо автору
 
   для: neadekvat   (06.11.2010 в 21:03)
 

ну так да, одной дополнительной проверкой меньше :)

  Ответить  
Rambler's Top100
вверх

Rambler's Top100 Яндекс.Метрика Яндекс цитирования