На том, что вы не можете понять, о чем идет речь уже битый час. И начинаете скатываться помаленьку на личности.
Нет, подожди, о чем речь идет? UPD: Ну так о чем, все-таки? UPD: ну все-таки? я же жду, а Вы меня игнорируете)))
по теме, - готовим юзеру ссылку с кучей необходимых параметров (ид юзера, дата ...) - на основе этих параметров и ИЗВЕСТНОЙ ТОЛЬКО НАМ СОЛИ - делаем ХЕШ, его тоже добавляем в ссылку юзеру, и посылаем на мыло. - юзер в почте кликает на ссылку и подтверждает то что нам нужно, а мы проверяем помимо параметров еще и ХЕШ, так как только мы знаем секретную соль плюсы: - ненадо делать в БД запись - подделать ссылку нереально - т.к. помимо параметров нужно подделать еще и ХЕШ, а это почти невозможно, ибо серверную СОЛЬ он незнает.
http://ru.wikipedia.org/wiki/HMAC Добавлено спустя 7 минут 6 секунд: не забываем про опасность повторного использования подсмотренного URL ! обеспечить одноразовость ссылки и при этом не добавлять новое поле можно так: 1) в хеше использовать существующий пароль 2) запретить повторную установку того же самого пароля
ТС я тебя прошу, рассказажи мне пошагово: как ты собираешься сменить пароль Васе Пупкину, зная токен для смены пароля Пети Васечкина? З.Ы. я хочу чтобы ты думал, а не выдумывал.
Пожалуй да, меньше телодвижений, просто генерим хешик и обливаем грязью, делаем отчет времени при переходе завершаем таймер, если пользователь обновит страницу просто так или перейдет по ссылке еще раз, ссылка не будет действительна, если отправит с новым паролем, меняем и ссылка уже не будет действительна. Одни плюсы.
как угодно. для простоты можно и одну из конфига юзать. либо можно юзать персональную соль юзера из бд. токен одноразовый, ограниченный по времени... поэтому и требования для него несколько другие нежели к хешу пароля например
А я що кажу) Объясняю. В смоделированной ситуации, которую описал Fell-x27, мы делаем рандомный токен (уникальный) и ложим его в табличку (неважно куда, прямиком в табличку к пользователю или же в другую табличку, которая связана с табличкой пользователя связью 1х1), а также рядом с токеном ложим "срок годности" токена. Ссылка, высылаемая пользователю на почту, имеет вид "http://example.com/restore?token=mytoken". Когда мы переходим по ссылке - наш скрипт берет токен, ищет в базе пользователя по данному токену и в случае, если пользователь находится, то мы берем из базы "срок годности" токена, проверяем - не истек ли он, если срок истек, то возвращаем 404 страничку или же уведомление о том, что срок истек. Если пользователь есть и "срок годности не истек", то мы выводим форму смены пароля. Так вот, Вы решили сменить пароль - соответственно в бд записались токен и "срок годности". Что мне мешает зайти на ссылку "http://example.com/restore?token=yourtoken", если я знаю Ваш токен и "срок годности".
Ну а если все равно уже юзаем БД, зачем выдумывать велосипед, если можно завязать изначально на ней? В ссылке строка рандомная, в БД хэш от нее, и дата окончания срока. Кликнули по ссылке - запись выпилилась из бд, вот тебе и защита от повторного срабатывания. Просто как апельсин. Добавлено спустя 51 секунду: Кто тебе мешает там хэш от него хранить, а не сам токен, как было описано ранее? Думать надо гибче. Тебе была дана концепция, суть которой - верификация не на основе входящих данных, а на основе сравнения "ожидание-реальность". Развивай как хочешь.
использование БД это один вариант. но на каждый чих создавать отдельную таблицу не всегда оправданно. Поэтому я предложил вариант - БЕЗ БД. юзать его или нет, и КАК его юзать - дело хозяйское. солью может быть что угодно. закодированный по определенному алгоритму логин, или пароль(как предложил artoodetoo)... главное чтобы атакующий незнал принцип формирования соли. можно туда подмешать еще Ip юзера или юзерагент. фантазия безгранична.
Ну так а зачем тогда надо было меня убеждать том, что у меня админ рукожоп, сервер - проходной двор, и что для того чтобы получить данные из бд - нужен доступ к управлению сервером?)))) Вы мне вчера весь мозг съели по поводу сервера) Я, конечно, извиняюсь за свои слова, которые написал вчера, но, блин, просто уже терпения не осталось) Сегодня же я свеж и весел))
даже если мы посылаем юзеру рандом, от которого считаем хеш (с логином и мыльником, и даже с паролем)... то если сервером владеет бармалей, ничего не мешает ему подменить хеш на сфабрикованный свой, чтобы сменить пароль тому, кто не просил. если мы рассматриваем задачу противодействия в случае, когда сервер зохваченг, то она не имеет решения.
Понятно. Читаем то, что хотим/ожидаем, а не то, что есть. Согласитесь, фраза "БД не светит в интернет и доступ к ней можно получить только через серверный скрипт, если конечно админ не рукожоп" не совсем эквивалентна фразе "твой админ - рукожоп".
Ну лады, наш админ не рукожоп)) Ну тогда ты мне покажи, где я написал что-то по поводу случая, когда мой сервер захвачен? Я тоже читаю... Не могу найти, хоть убей))
igordata, сервером никто не владеет)) Такая ситуация, конечно, не исключена, но все же... В таком случае, я думаю, задачи несколько иные и вряд ли связаны с безопасной сменой пароля)
artoodetoo, по поводу одноразовости ссылки, с паролем не получится, наверное, если конечно не иметь ввиду, что одноразовость подразумевает одну смену пароля, а не заход на страницу.
Хорошо, вот тебе еще вариант: у тебя есть рандомный токен для смены пароля, по которому ты находишь юзера. Можешь добавить в сессию еще 1 токен для верификации того, кому ты этот токен создавал. Или подмешать его к первому токену. Тут много чего придумать еще можно. Но состязание в метком метании ссаных тряпок во всех кто говорит, что ничего ужасающего с твоей базой не произойдет, устраивал тут зря.