Школа
Интерфейс

При запросе восстановления пароля сайты высылают подтверждение, при нажатии на ссылку генерируется новый пароль и высылается второе письмо

Раньше при регистрации на сайты просили указывать секретный вопрос и ответ к нему, чтобы по этим данным выслать старый пароль или сгенерировать новый.

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

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

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

Ильдар Хайруллин
22 ноя 2010
👁 6195   🗩7
Интерфейс

При запросе восстановления пароля сайты высылают подтверждение, при нажатии на ссылку генерируется новый пароль и высылается второе письмо

Раньше при регистрации на сайты просили указывать секретный вопрос и ответ к нему, чтобы по этим данным выслать старый пароль или сгенерировать новый.

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

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

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

Ильдар Хайруллин
22 ноя 2010
👁 6195   🗩7
А. Г.
Арт‑директор и автор учебных программ бюро
Полезно
  
Непонятно
  
Войдите в Бюросферу, чтобы голосовать

Этот универсальный дизайнерский приём называется «объединение»: подтверждение и обновление объединяются в одно действие для упрощения сценария.

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

Этот универсальный дизайнерский приём называется «объединение»: подтверждение и обновление объединяются в одно действие для упрощения сценария.

Однако присылание нового пароля — исключительно бесполезная мера. Если вы не Человек дождя, вы никогда его не выучите. Эта процедура в итоге просто заменит собой обычный ежедневный вход на сайт, особенно если вы не даёте браузеру запоминать пароли.

Если пароль забыт, стоит присылать ссылку на страницу со сменой пароля и не слишком усердствовать с проверкой на «криптостойкость». Никогда не забуду, как минут двадцать пытался придумать новый пароль к Фейсбуку.

Проектирование сценарияРегистрация пользователяОбъединение элементовИнтерфейсНоситель: сайт
Полезно
  
Непонятно
  
Войдите в Бюросферу, чтобы голосовать
Отправить
Поделиться
Поделиться
Запинить
Твитнуть

Комментарии

У себя реализовал такой вариант: в базе данных хранятся два пароля. Первый создаётся при регистрации пользователем, второй по умолчанию пуст. Если пользователь просит напомнить ему пароль, генерируется новый, записывается в базу данных как второй, и высылается на почту пользователю. В этот момент возможен вход по любому паролю. При входе с новым паролем — новый заменяет в базе первый и дальше используется как основной.

При желании можно при первом входе пользователя с новым паролем предлагать изменить его.

Можно сделать легко запоминаемым и автоматически сгенерированный пароль. Для этого надо генерировать не случайные символы (например, xgukj7g), а случайные слоги (surituga). В итоге пароль можно произнести и гораздо проще запомнить.

Устойчивость к паролю падает незначительно (можно компенсировать парой лишних букв). Код генерации подобного тоже ужасно прост (массив с согласными и гласными и n/2 раза выбираем случайную пару из них).

Мне кажется, нужно исходить из того, какая возникает проблема.

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

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

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

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

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

Простите за американизм понимания что важно, а что нет, но, на мой взгляд, важным является следущее:
— пароли к почте, к аккаунтам в социальных сетях, где злоумышленник может выудить персональную информацию других пользователей;
— пароли к файловым хранилищам, фотобанкам и прочим сайтам, где может храниться личная информация пользователя;
— пароли к банковским счетам или даже к сайтам, позволяющим получить данные к непубличным расходам пользователя (пароли к отелям, и магазинам подходят в эту же категорию);
— пароли к доменам и ДНС информации (получив контроль над которыми, можно стащить часто больше, чем с почтового адреса);
— пароли к более серьёзным вещам — адвокатской, медицинской, государственной информации;
— пароли к административным аккаунтам любой системы с большим числом пользователей.

Зная, как несерьёзны порой провайдеры и сайты электронной почты в своих требованиях к паролям (плюс порой провайдеры доменной регистрации и ДНС), я бы рекомендовал не полагаться только на почту (истории известных компаний, потерявших пароли таким образом, вы найдёте на Техкранче).

Как сказал Ильдар в вопросе первое, что приходит в голову — спросить при регистрации что‑нибудь ещё и попросить повторить. Банки в США используют дату рождения и последние четыре цифры номера соцстрахования, провайдеры специальных услуг используют ключевые шаблоны и электронные кодогенераторы типа mypw.com. Многие полагаются на почту, хотя от этого пора отходить.

Простые регистрационные вопросы могут быть такими, чтобы было сложно забыть ответ: «ваш любимый школьный учитель», «ваш любимый театр в детстве», «сколько у вас пломб в зубах?». Нужно просто подумать вместе с командой и остановиться на наборе достойных вопросов.

Теперь о том, что не является серьёзным. Попробую придумать примеры.
— пароли для настройки цветов/шрифта/фильтрации новостей на некоторых сайтах;
— пароли для скачивания известных программ и их обновлений, когда они не представляют особой ценности;
— пароли для всякого и без того малозаконного — обмена фильмами/музыкой и т. п.Пользователям явно неинтересно иметь много «хвостов» в таких системах;
— пароли для чтения газет и журналов с «бесплатной, но необходимой регистрацией».

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

В любом случае обязательно нужно пользоваться SSL сертификатами. Умников, слушающих вайфай в интернет‑кафе и домашних сетях, хватает. Открыто передавая пароли по сети, вы имеете вероятность 50%, что их стащат. Имея систему с миллионом пользователей и подобным пренебрежением к безопасности канала, сайты даже с самым секретным способом восстановления пароля будут гарантированно терять акаунты.

Забытый пароль логичнее напоминать. Просто, письмом, без секретных вопросов и подтверждений. Такие системы, например, проектируют ребята из 37 сигналов (см. восстановление пароля на Writeboard).

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

Сценарии могут быть разными (это описано выше) и зависеть от «степени секретности» данных на сайте. Но ключевой вопрос, который нужно решить разработчикам системы, это хранить ли пароль в БД в открытом виде или в виде хэша.

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

Когда Вконтакте прислал мне мой старый забытый пароль на почту, я был в шоке. Они хранят пароли в открытом виде! Это значит, что всю базу паролей можно украсть, продать и т. п.

Помните, не знать паролей своих пользователей — это благо. Если, конечно, вы не злоумышляете.

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

Рекомендуем другие советы