Реализация передового опыта восстановления пароля

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

Я хотел бы избежать использования секретных вопросов.

Я мог бы просто отправить пароль по электронной почте, но я думаю, что это было бы рискованно.

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

Могу ли я отправить URL-адрес, например, по электронной почте http://example.com/token=xxxx где xxxx - это случайный токен, связанный с пользователем. Поэтому, когда пользователь переходит к этому URL-адресу, он может сбросить пароль.

источник

2010-04-29 Enrique

возможно дубликат HTTP: // StackOverflow.com/вопросы/910856/эффективные методы для поиска паролей в современных веб-приложениях –

ps. Когда пользователь приходит на страницу сброса пароля с правом токеном, продолжайте использовать этот токен (или другой временный токен), чтобы обновить правильную запись в форме submit с новым паролем. Если вместо этого вы используете что-то вроде идентификатора записи (после того, как нашли нужную запись), люди могут сбросить пароль друг друга, используя это вместо токена. Я только что узнал, когда писал один из них :-) – MSpreij

Проверить аналогичный вопрос on IT Security (StackExchange) http://security.stackexchange.com/questions/1918/can-anyone-provide-references-for-implementing-web-application-self-password-res –

Прежде всего, сделать не хранить текстовую копию пароля пользователя или даже зашифрованную версию. Вы хотите только сохранить хешированную копию пароля пользователя.

Что касается восстановления решений, я обнаружил, что ссылка на восстановление для изменения пароля пользователя является лучшим решением в моем опыте. Вероятно, это будет немного более удобным для пользователя, хотя в то же время он будет в значительной степени идентичным с точки зрения безопасности, поскольку посылка нового случайного пароля будет изменена после следующего входа в систему. Я по-прежнему рекомендую, чтобы срок действия восстанавливаемого url истекал через разумный короткий промежуток времени, а также был доступен только один раз.

источник

2010-04-29 02:13:21 Kitsune

Я собираюсь попытаться реализовать это в первый раз. Я только сохраняю хэшированные пароли, как вы говорите, не могли бы вы немного рассказать о методе ссылки на восстановление. Я видел, как это делалось с таким: http: //site.com/reset-pass? E = '+ user.email +' & p = '+ user.pass', где поле пароля является хэшем, является ли это безопасным ? Если кто-то задерживает хеши для вашей базы данных, означает ли это, что они могут сбросить пароль каждого? Как бы вы реализовали ссылки, срок действия которых истекает? –

@CoryGross Существуют различные способы, по которым вы можете это сделать, но вы определенно не хотите, чтобы ссылка каким-либо образом отображала электронную почту или передает/хеш. Достаточно простой вариант - это дополнительная таблица в вашей базе данных, столбец идентификатора пользователя (уникальный), столбец данных запроса и * случайное сгенерированное * значение (128 бит - безопасное значение). Случайно сгенерированное значение будет включено в ссылку в электронном письме. Страница сброса-подтверждения гарантирует, что номер, который он получает, находится в базе данных, а дата - в течение X дней. В этот момент вы можете запросить новый пароль для пользователя. Чернослив периодически. – Kitsune

Каким будет «короткий период времени»? Часы? Дни? Неделя? – Joe

Очевидно, что вы не можете отправить оригинальный пароль по электронной почте, потому что вы его не храните (правильно ?!). Отправка временного пароля (который должен быть изменен, поскольку он работает только для одного входа в систему), а ссылка для сброса пароля эквивалентна с точки зрения безопасности.

источник

2010-04-29 02:12:33

Я сохраняю пароль с AES-шифрованием, чтобы я мог расшифровать его и отправить. – Enrique

+12

В действительности нет веских оснований для хранения паролей в обратимом формате, и, вероятно, использование симметричного алгоритма, как это, добавит нулевой дополнительной безопасности, добавив только ложное чувство безопасности. Используйте правильный алгоритм хеширования, такой как один из семейства SHA, или водоворот, или другой современный, с солью, а пароли будут более безопасными. – Kitsune

+11

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

Это действительно сводится к тому, насколько обеспечена безопасность. Одним из крайних пределов является процесс сброса пароля, который включает в себя обращение и подтверждение того, что вы являетесь тем, кем вы являетесь, например. через id, поскольку ваш почтовый ящик также может быть скомпрометирован. Фактически, поскольку люди, как правило, используют один и тот же пароль во всем мире, это очень вероятно. С другой стороны, существует стандартный подход, который включает в себя просто отправку электронной почты с помощью случайного нового пароля.

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

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

Просто убедитесь, что токен используется только один раз и предпочтительно только в течение ограниченного промежутка времени, например. + 24h после запроса.

И, как указано в предыдущих ответах, НИКОГДА не сохраняйте простые пароли. Хеши их. Предпочтительно добавить salt.

источник

2010-04-29 02:50:12 ilikeorangutans

Разница между токеном и случайным паролем не очень важна в безопасности, но это возможность для отказа в обслуживании. Не изменяйте пароль пользователя, если они явно не спрашивают. – Duncan

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

Я видел много сайтов, которые используют «перейдите по этому URL для сброса пароля».Может быть, я что-то пропустил - я не утверждаю, что я эксперт по безопасности, но я не понимаю, как это безопаснее, чем просто изобретать новый временный пароль и отправлять его. Если хакер перехватывает электронное письмо, почему он не может перейти к этой ссылке и не видит новый пароль, а также законный пользователь? Мне кажется, что это лишний хлопот для пользователя без усиления безопасности.

Кстати, поздравляю с НЕ использованием вопросов безопасности. Логика этого устройства ускользает от меня. С самого начала компьютерной безопасности мы говорили людям: «НЕ делайте пароль, который является информацией о себе, которую хакер может обнаружить или угадать, например, имя вашей средней школы или ваш любимый цвет. Возможно, хакер чтобы узнать имя своей средней школы, или даже если они не знают вас или ничего не знают о вас, если вы все еще живете рядом с тем, куда вы ходили в школу, они могли бы получить его, пытаясь найти местные школы, пока они не ударят. небольшое количество вероятных любимых цветов, чтобы хакер мог догадаться об этом. И т. д. Вместо этого пароль должен быть бессмысленной комбинацией букв, цифр и знаков препинания ». Но теперь мы также говорим им: «Но! Если у вас есть трудное время, помня о том, что бессмысленное сочетание букв, цифр и знаков препинания, не проблема! Возьмите некоторую информацию о себе, которую вы легко можете вспомнить, - например, название вашей средней школы , или ваш любимый цвет - и вы можете использовать это как ответ на «вопрос безопасности», то есть как альтернативный пароль ».

Действительно, вопросы безопасности делают его еще проще для хакера, чем если вы только что выбрали неверный пароль для начала. По крайней мере, если вы просто использовали личную информацию для своего пароля, хакер не обязательно знал бы, какую часть личной информации вы использовали. Вы использовали имя своей собаки? Дата рождения? Ваш любимый аромат мороженого? Он должен попробовать всех. Но с вопросами безопасности мы говорим хакеру точно, какую часть личной информации вы использовали в качестве пароля!

Вместо того, чтобы использовать вопросы безопасности, почему бы нам просто не сказать: «Если вы забыли свой пароль, он отображается в нижней части экрана. Если вы пытаетесь взломать чужую учетную запись, вы абсолютно запрещено прокручивать ». Это было бы чуть менее безопасно.

Чтобы вас не интересовало, когда сайты спрашивают меня о городе, где я родился, или о производителе моей первой машины, я не даю ответа на вопрос. Я даю бессмысленный пароль.

</декламация>

источник

2010-04-29 04:11:49 Jay

+37

+1 Для большинства приятных размышлений о том, почему вопросы безопасности плохи. – Peter

Я всегда выбираю неясные ответы на эти ужасные вопросы «безопасности». У меня был неловкий момент, когда мой беспроводной провайдер восстановил мой пароль по телефону. Они задали мне один из вопросов безопасности, которые я задал: «Какая ваша любимая еда?», На что я ответил: «Я» ... «Э-э, хорошо, мистер Мурч, спасибо вам большое». –

@ Уэсли: Это могло быть хуже. Вы могли бы сказать, «люди службы поддержки». Неплохая идея. Нелепого ответа было бы легко запомнить, но менее вероятно, чтобы кто-то догадался. Пока вы не выбираете явный нелепый ответ. Например, Q: «Куда вы пошли в школу?» A: «Жесткие удары». – Jay

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

Однако то, что вы не должны делать:

Отправить пароль - потому что в конце концов, как уже упоминалось, вы не имеете его.
Создайте новый временный пароль - это не только небезопасно, как отправка пароля, но и приводит к возможности атаки на отказ в обслуживании. Я могу зайти на сайт, притвориться вам, запросить новый пароль, а затем (если вы не проверили свой адрес электронной почты), вы не можете войти в систему, не знаете, почему и нужно запросить новый новый пароль. .

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

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

источник

2010-04-29 05:08:44 Duncan

Я не игнорирую отношение к секретному методу вопроса. Не похоже, что я сделаю свой пароль «BlueHouse», а затем сделаю свой вопрос безопасности «Каковы ваши две любимые вещи?» и ответ «Синий и дом». Вопрос безопасности не является волшебным ключом для получения фактического пароля. Обычно это способ получить новый пароль, отправленный на адрес электронной почты в файле. Я не знаю, как еще вы это делаете, но похоже, что вы делаете одну из двух вещей.

1) Пользователь нажимает кнопку «Я забыл свой пароль», и новый пароль отправляется пользователю.

2) Пользователь нажимает кнопку «Я забыл свой пароль», а затем должен ответить на секретный вопрос, прежде чем получать новый пароль по электронной почте по адресу в файле.

Кажется, что вариант номер 2 более безопасен.

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

источник

2011-03-16 17:48:34

«Мне кажется, что вариант номер 2 более безопасен» ... да, но только тривиально, и это раздражает пользователей, и они забывают ответы. – Mark

Проблема с секретным вопросом заключается в том, что вопросы, как правило, такие вещи, как «девичья фамилия матери» или «где вы учились в школе», вещи, которые часто можно почерпнуть из профиля социальной сети; если пользователю разрешено вводить свой секретный вопрос, он обычно еще слабее. Согласитесь, что если учетная запись электронной почты взломана, все ставки отключены, хотя имейте в виду, что на многих сайтах возникают секретные вопросы в качестве альтернативы использованию ссылки на сброс пароля, т. Е. Получить секретный вопрос, и вы сразу перейдете к сбросу пароля , – Duncan

Что касается отправки токена и отправки нового пароля, если вы отправляете новый пароль, как напрямую, так и после ответа на вопрос безопасности, это требует, чтобы пароль был сброшен, что заблокирует пользователя из их учетной записи, если они 't запрашивать новый пароль (и не проверял их электронную почту). Это атака DOS, где, если хакер не может войти в учетную запись пользователя, то и пользователь не может. И наоборот, токен - это просто аутентификация для изменения пароля. Если пользователь не запрашивал его или не помнил свой старый пароль, он может игнорировать его, и он будет или должен истекать. – Duncan

Я согласен с Энди. Как правило, вопросы безопасности не зависят от пароля? (мои). У них есть вопрос и ответ, и они не связаны с паролем. Похоже, что это используется для предотвращения ложных запросов на сброс пароля и фактически имеет смысл.

Представьте, что кто-то может перейти к утилите «забытый пароль» сайта и ввести миллионные адреса электронной почты - или просто один человек, которого они хотят раздражать. Если пароль сбрасывается в этот момент, люди, принадлежащие к этим адресам электронной почты, должны будут затем заметить в своем письме сброс пароля и войти на сайт со сбросом пароля в следующий раз, когда они туда поедут. С вопросом безопасности это не так просто для кого-то сделать.

Я вижу, что Amazon отправляет ссылку на данное письмо. Они также требуют, чтобы вы вводили капчу, чтобы предотвратить атаки DOS. Поскольку это ссылка, я предполагаю, что это означает, что они не сразу сбросили пароль, и он будет сброшен, как только пользователь нажмет на ссылку. В приведенном выше сценарии пользователь просто увидит сообщение электронной почты и заметит, что «нет, я этого не делал», и продолжаю заниматься своим делом, не требуя лишнего изменения пароля. Защитный вопрос, возможно, помешал попытке в начале и законному пользователю получить электронное письмо в первую очередь.

Вот официальный документ на нем: http://appsecnotes.blogspot.com/2010/09/latest-forgot-password-best-practices.html

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

источник

2011-04-20 15:57:43 mikato

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

Что касается безопасности вопрос/ответ. Как пользователь сайтов, я лично их не использую (я ввожу в них мусор). Но они, конечно, не бесполезны или бессмысленны, как говорят некоторые из них.

Рассмотрите эту ситуацию: Пользователь вашего сайта покинул свой стол, чтобы пойти на обед и не заблокировал его рабочую станцию.Теперь злоумышленник может посетить страницу для восстановления/сброса пароля и ввода имени пользователя. Затем система отправит пароль восстановления/сброса, не запрашивая ответ на запрос безопасности.

источник

2013-04-19 00:15:12 Magnus

, но почему предположить, что гнусный человек не имеет доступа к вопросам безопасности? Все, что я смогу запомнить сам, например. девичья фамилия матери, родоначальник, первое домашнее животное и т. д. НЕ секретная информация. Я мог бы вести блог, чирикать или упоминать его в случайном разговоре. Таким образом, люди вокруг моего стола, которые, скорее всего, получат доступ к моему компьютеру, также будут знать мои «секретные» ответы на безопасность. Это, безусловно, легко открыть для социальной инженерии. – yochannah

@yochannah, я согласен, что он не обеспечивает надежную защиту, но, как я уже сказал, это бесполезно. Проблема может заключаться в том, что она дает пользователю ложное ощущение хорошей безопасности, но я бы не сказал, что это мотивирует нас не включать эту функцию вообще. – Magnus

@Jay. Правильное использование вопросов безопасности заключается в том, чтобы инициировать сброс пароля с паролем, а не для фактического сброса пароля. Без такого механизма, как вопрос безопасности, можно инициировать сброс пароля. Хотя, похоже, beign, отправка сброса электронной почты может быть отправлена на электронную почту, которая больше не может принадлежать первоначальному владельцу. Это не редкость. Например, когда сотрудники покидают компанию, часто эти письма отправляются другому сотруднику. Защитный вопрос добавляет низкий уровень увлечения к этому сценарию. Это также уменьшает проблемы, когда один человек продолжает инициировать сброс пароля на неправильную учетную запись, что приводит к тому, что какой-то плохой дерн случайно попадает в спам. Вопрос безопасности действительно не предназначен для того, чтобы быть действительно безопасным, они предназначены только для сокращения таких сценариев. Любой, кто использует секретный вопрос для фактического сброса пароля, делает это неправильно.

источник

2013-07-24 06:39:55 Devon

@Jay. Причина, почему вы переходите к URL-адресу для сброса пароля вместо того, чтобы просто отправлять кому-то новый временный пароль, - это больше, чем просто безопасность. Без чего-то вроде URL-адреса с токеном, человек может сбросить пароль других лиц. Нет необходимости получать доступ к электронной почте. Если у кого-то есть кость, чтобы выбрать кого-то, они могли бы просто начать новый сброс пароля. Затем бедной цели необходимо войти в систему и изменить пароль снова и снова.

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

Кроме того, поскольку GUID уникален (сгенерированный пароль может и не быть), токен может быть привязан к имени пользователя. Если неверное имя пользователя указывается в URL-адресе, то токен может быть отменен (т. Е. Когда другой человек инициирует его, а кто-то его перехватывает), предполагая, что имя пользователя не совпадает с именем электронной почты).

источник

2013-07-24 07:07:51 Devon

Вот как я решил это:

Я добавил retrieve_token и retrieve_expiration поля к моему столу 'пользователей.

Пользователь запрашивает сброс пароля, предоставляя свою электронную почту и заполняя captcha. Произвольное хешированное значение генерируется для своего поля retrieve_token, то есть md5($user_id.time()), тогда как retrieve_expiration будет установлено в дату и время, истекающее через следующие 45 минут. Электронная почта отправляется пользователю со ссылкой:

https://example.com/reset-password?retrieve_token=912ec803b2ce49e4a541068d495ab570

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

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

источник

2013-12-06 23:48:28 bazzaretta

Вот пример того, как кто-то сделал это с Node.js, в основном генерирует случайный токен, время истечения срока действия, отправляет ссылку с прикрепленным токеном, имеет маршрут reset/:token, который гарантирует, что пользователь существует с этим токеном (который также не истек), и если да, перенаправите страницу восстановления пароля.

http://sahatyalkabov.com/how-to-implement-password-reset-in-nodejs/

источник

2014-08-18 16:45:25 Leahcim

Реализация передового опыта восстановления пароля

ответ

Смежные вопросы