восстановление пароля
- Автор темы snitko
- Дата начала
kruglov
Новичок
При забытии пароля генерим случайное число, пишем его в базу и шлем его же в ссылке пользователю. Если пользователь пароль меняет, случайное число стираем. Если жмет на "забыл пароль" второй раз, высылаем ему уже запомненное в прошлый раз число. Из параноидальных соображений можно внести элемент устаревания числа.
GeT
Новичок
Да, я так же делаю.
1. При вводе e-mail (или логина) в восстановление пароля, на e-mail пользователя отправляется письмо с ключом (ключ пишется в БД разумеется).
2. Пользователь получает этот e-mail, кликает на ссылку с ключом и получает на свой e-mail новый пароль.
У "злоумышленника", который не имеет доступа к e-mail пользователя, при таком раскладе никаких шансов
1. При вводе e-mail (или логина) в восстановление пароля, на e-mail пользователя отправляется письмо с ключом (ключ пишется в БД разумеется).
2. Пользователь получает этот e-mail, кликает на ссылку с ключом и получает на свой e-mail новый пароль.
У "злоумышленника", который не имеет доступа к e-mail пользователя, при таком раскладе никаких шансов
Духовность™
Продвинутый новичок
Зачем что-то писать в базу - делать лишнюю работу?
- Пользователь вводит свой емейл - делает запрос.
- Если такой емейл в БД есть - отсылаем в письме ссылку с хешем от md5(логин+секретное_слово)
- При заходе пользователя по уникальной ссылке меняем пароль на новый, где MD5(CONCAT(user_login, $secret_string)) == $_GET['hash']
- Пользователь вводит свой емейл - делает запрос.
- Если такой емейл в БД есть - отсылаем в письме ссылку с хешем от md5(логин+секретное_слово)
- При заходе пользователя по уникальной ссылке меняем пароль на новый, где MD5(CONCAT(user_login, $secret_string)) == $_GET['hash']
Духовность™
Продвинутый новичок
kruglov
$secret_string всегда разная - устанавливается модератором.
$secret_string всегда разная - устанавливается модератором.
hammet
Новичок
если так боишься - то по запросу генерируй новый пароль, меняй его в базе и отправляй его же на мыло 
Единственная проблема - мыло может не дойти, а пароль уже новый) тогда можно сделать операцию повторно.
Но никто никаких secret_word у тебя красть не будет и ты будешь спать спокойно
Единственная проблема - мыло может не дойти, а пароль уже новый) тогда можно сделать операцию повторно.
Но никто никаких secret_word у тебя красть не будет и ты будешь спать спокойно
igortik
Новичок
Больше все же понравилась идея с авто-логином по ссылке и предложению юзеру сразу сменить пароль.
Но в простом методе с простым хешем пароля в линке 1 недостаток - это прямая помощь кул-хацкеру))) подобрать пароль.
1) Возможно использовать этот метод и немного его усложнить, например в линке отправить конкатенацию хешей логина, пароля и мыла. Здесь хрен определишь какой из кусков хеш пароля, а вот мы-то знаем как обработать эту строку.
Для максимальной вероятности сбить с толку можно еще и первый и последний хеш порезать по длине в линке, чтобы общая сумма символов отличалась от 3х-хеш.
2) Можно и в открытом виде хранить пароли, учитывая, что внешние соединения к базе невозможны (разрешен лишь локальный доступ) и, в первую очередь, пароль на ftp !='123'.
3) Еще метод менять пароль по секретному вопросу. Юзер ввел мыло, дал ответ на вопрос и ему пришел новый пароль. Но есть один недостаток - "я не помню ответ на вопрос, т.к. ввел значение от балды".
p.s. обычный ресет пароля по вводу мыла не канает по ясным причинам.
Все же больше склонен к первому методу, т.к. таблица с открытыми паролями и хорошим паролями на фтп (можно ограничить по ip) это конечно же круто :lol:
Но если любопытный провайдер захочет с таких проектов подоить базы в целях возможности получить доступ к ящикам юзеров (многие вводят везде один и тот же пароль, что на мыле)...
мля, все.. сил больше нет писать... сори, что поднял тему.. сейчас тоже актуальный вопрос.. все же буду создавать головоломку по 1 пунтку
-~{}~ 29.05.09 21:45:
с другой стороны, что мешает злоумышленнику самому проанализировать ссылку длиной 3х-кешей и просто сравнив ее с мд5(свой_пароль).... а потом просто перебирать пароли (их хеши), пока не авторизируется под кем-то...
Но в простом методе с простым хешем пароля в линке 1 недостаток - это прямая помощь кул-хацкеру))) подобрать пароль.
1) Возможно использовать этот метод и немного его усложнить, например в линке отправить конкатенацию хешей логина, пароля и мыла. Здесь хрен определишь какой из кусков хеш пароля, а вот мы-то знаем как обработать эту строку.
Для максимальной вероятности сбить с толку можно еще и первый и последний хеш порезать по длине в линке, чтобы общая сумма символов отличалась от 3х-хеш.
2) Можно и в открытом виде хранить пароли, учитывая, что внешние соединения к базе невозможны (разрешен лишь локальный доступ) и, в первую очередь, пароль на ftp !='123'.
3) Еще метод менять пароль по секретному вопросу. Юзер ввел мыло, дал ответ на вопрос и ему пришел новый пароль. Но есть один недостаток - "я не помню ответ на вопрос, т.к. ввел значение от балды".
p.s. обычный ресет пароля по вводу мыла не канает по ясным причинам.
Все же больше склонен к первому методу, т.к. таблица с открытыми паролями и хорошим паролями на фтп (можно ограничить по ip) это конечно же круто :lol:
Но если любопытный провайдер захочет с таких проектов подоить базы в целях возможности получить доступ к ящикам юзеров (многие вводят везде один и тот же пароль, что на мыле)...
мля, все.. сил больше нет писать... сори, что поднял тему.. сейчас тоже актуальный вопрос.. все же буду создавать головоломку по 1 пунтку
-~{}~ 29.05.09 21:45:
с другой стороны, что мешает злоумышленнику самому проанализировать ссылку длиной 3х-кешей и просто сравнив ее с мд5(свой_пароль).... а потом просто перебирать пароли (их хеши), пока не авторизируется под кем-то...
igortik
Новичок
dimagolov
второе есть чуть-чуть.
Я вот не пойму в чем позор.
Я мысли по-своему выражаю, но это не помешает мне сгенерить ссылку с любым методом шифрования ключа, юзер_id и т.п.
Алгоритм разбора строки также зависит от его создателя.
Но принципы везде одни и какая хрен разница как о них говорить или писать.
Ясно одно, что если сервер собственный, где лежит проект, то можно и нужно, на мой взгляд, держать пароли открытыми, т.к. юзер захочет восстановить и проще ему его выслать в таком виде, в каком он его вводил и также дать ему ссылку.
Также можно давать помимо пароля еще и ссылку на его смену с ОБЫЧНЫМ ХЕШЕМ ПАРОЛЯ, по хешу будет выбран e-mail юзера и его стоит попросить ввести e-mail для подтверждения и свой НОВЫЙ пароль.
В этом случае злоумышленнику придется знать мыло жертвы и хеш пароля.
"орбит" говоришь ? )))
второе есть чуть-чуть.
Я вот не пойму в чем позор.
Я мысли по-своему выражаю, но это не помешает мне сгенерить ссылку с любым методом шифрования ключа, юзер_id и т.п.
Алгоритм разбора строки также зависит от его создателя.
Но принципы везде одни и какая хрен разница как о них говорить или писать.
Ясно одно, что если сервер собственный, где лежит проект, то можно и нужно, на мой взгляд, держать пароли открытыми, т.к. юзер захочет восстановить и проще ему его выслать в таком виде, в каком он его вводил и также дать ему ссылку.
Также можно давать помимо пароля еще и ссылку на его смену с ОБЫЧНЫМ ХЕШЕМ ПАРОЛЯ, по хешу будет выбран e-mail юзера и его стоит попросить ввести e-mail для подтверждения и свой НОВЫЙ пароль.
В этом случае злоумышленнику придется знать мыло жертвы и хеш пароля.
"орбит" говоришь ? )))
dimagolov
Новичок
данную тему тут достаточно часто обсуждают, сходи в поиск, почитай что пишут (на трезвую голову), тогда поймешь, что все из написанного тобой выглядит по меньшей мере смешно.
-~{}~ 29.05.09 17:14:
п.с. у нас, кстати, программера одного ушли потому что он регулярно вечерами накачивался пивом, а по утрам с бодунища добавлял новые баги к уже имеющимся вместо того, чтобы их править.
igortik
Новичок
алкоголь - зло, это точно 
можно, но в меру.
-~{}~ 30.05.09 02:44:
вот только что изобрел велосипед, по-моему, но мыслями поделюсь.
Рассмотрим вариант, когда необходимо держать пароли в базе ТОЛЬКО в форме хеша и нужно дать юзеру возможность менять пароль по ссылке, которая придет на мыло.
1. Пользователь отправляет заявку на смену пароля.
- Заявке генерируется уникальный хеш и пишется в отдельную таблицу, где также в поле пишется ID пользователя и time()+какой-то интервал активности с момента создания.
2. Пользователь открывает полученное письмо и идет по ссылке с хешем (сгенер. в п.1)
3. Скрипт ищет в таблице с заявками соответствующую запись по хешу, пришедшему через GET
- в случае существования записи либо логиним юзера, либо отдаем ему форму на смену пароля
- пароль по факту поста формы меняем именно тому ID, который указан в таблице с заявкой.
4. По факту смены пароля убиваем из заявок все записи по id пользователя (заявка может быть не одна, если временной интервал по смене пароля был просрочен для какой-то из них)
Что мы имеем:
1. Никаких дополнительных ключей, соли и записей в базу в основные таблицы и никаких передач личных данных юзера по ссылке.
2. Только владелец почтового ящика может получить ссылку (юзер сам ввел свой адрес для получения ссылки).
3. Если юзер забыл удалить сообщение (оно осталось у него в корзине, продублировалось на левый e-mail и т.д.), то хеш, указанный в ссылке ничего не даст, т.к. он принадлежит заявке, которая удаляется из базы по факту смены пароля, либо по истечению, например, 5 минут. Т.е. если уж кому-то и нужен сильно пароль, то он должен ловить юзера в минуты его смены!
Остаются лишь вопросы по автоматической чистке базы, ведь рано или поздно, там будут оставаться активные заявки, к которым так и не обратились.
Но этот вопрос вполне легко решить разными методами.
Ну и, конечно же, безопасность самого почтового ящика может гарантировать только пользователь.
p.s. главное, что сервер никаких личных данных не отдает по этому запросу, пусть даже в виде хеша...
можно, но в меру.
-~{}~ 30.05.09 02:44:
вот только что изобрел велосипед, по-моему, но мыслями поделюсь.
Рассмотрим вариант, когда необходимо держать пароли в базе ТОЛЬКО в форме хеша и нужно дать юзеру возможность менять пароль по ссылке, которая придет на мыло.
1. Пользователь отправляет заявку на смену пароля.
- Заявке генерируется уникальный хеш и пишется в отдельную таблицу, где также в поле пишется ID пользователя и time()+какой-то интервал активности с момента создания.
2. Пользователь открывает полученное письмо и идет по ссылке с хешем (сгенер. в п.1)
3. Скрипт ищет в таблице с заявками соответствующую запись по хешу, пришедшему через GET
- в случае существования записи либо логиним юзера, либо отдаем ему форму на смену пароля
- пароль по факту поста формы меняем именно тому ID, который указан в таблице с заявкой.
4. По факту смены пароля убиваем из заявок все записи по id пользователя (заявка может быть не одна, если временной интервал по смене пароля был просрочен для какой-то из них)
Что мы имеем:
1. Никаких дополнительных ключей, соли и записей в базу в основные таблицы и никаких передач личных данных юзера по ссылке.
2. Только владелец почтового ящика может получить ссылку (юзер сам ввел свой адрес для получения ссылки).
3. Если юзер забыл удалить сообщение (оно осталось у него в корзине, продублировалось на левый e-mail и т.д.), то хеш, указанный в ссылке ничего не даст, т.к. он принадлежит заявке, которая удаляется из базы по факту смены пароля, либо по истечению, например, 5 минут. Т.е. если уж кому-то и нужен сильно пароль, то он должен ловить юзера в минуты его смены!
Остаются лишь вопросы по автоматической чистке базы, ведь рано или поздно, там будут оставаться активные заявки, к которым так и не обратились.
Но этот вопрос вполне легко решить разными методами.
Ну и, конечно же, безопасность самого почтового ящика может гарантировать только пользователь.
p.s. главное, что сервер никаких личных данных не отдает по этому запросу, пусть даже в виде хеша...
igortik
Новичок
действительно хорошая идея по очистке!
по поводу хеша, я полагаю, будет достаточно:
1. Применяем какую-то математическую функцию к ID юзера
2. Конкатенируем с e-mail (можно написать функцию для перевода лат. букв мыла в числа, а все остальное отбрасываем).
3. Получаем хеш от данной пары.
В итоге, если хеш и вскроют, чтобы посмотреть метод, то это затруднит понимание полученной строки, т.к. там будут одни числа
А если сайт где-то упоминает ID юзера, то лучше показывать фиктивные значения, которые потом будут обрабатываться, чтобы совсем запустать.. (но это уже немного иная тема)
p.s. здесь уже фантазия решает.
по поводу хеша, я полагаю, будет достаточно:
1. Применяем какую-то математическую функцию к ID юзера
2. Конкатенируем с e-mail (можно написать функцию для перевода лат. букв мыла в числа, а все остальное отбрасываем).
3. Получаем хеш от данной пары.
В итоге, если хеш и вскроют, чтобы посмотреть метод, то это затруднит понимание полученной строки, т.к. там будут одни числа
А если сайт где-то упоминает ID юзера, то лучше показывать фиктивные значения, которые потом будут обрабатываться, чтобы совсем запустать.. (но это уже немного иная тема)
p.s. здесь уже фантазия решает.