Как сохранить пароли в безопасности, когда доступна функция «Забыли пароль»

Question

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

Мы уже решили, что для создания учетной записи потребуется три обязательных элемента

1) Имя экрана
2) Адрес электронной почты (используется для входа)
1) Пароль (очевидно, также используется для входа в систему. Хранится как односторонний хэш )

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

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

Идея 1

1. Пользователь нажимает кнопку «Забыли пароль»
2. У пользователя запрашивается адрес электронной почты его учетной записи
3. Если электронная почта соответствует активной, не закрытой учетной записи, отправьте временный пароль на уже подтвержденный адрес электронной почты
4. Пользователь пытается войти с временным паролем
5. Если временный пароль совпадает с адресом электронной почты, попросите пользователя сбросить пароль. Запретить полный вход в систему до замены временного пароля.

Идея 2

Это потребует сбора секретных вопросов и секретных ответов во время регистрации.

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

Беспокойство

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

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

Сводка вопроса

Учитывая внутренние эксплуатационные ограничения (от нескольких человек до единого входа), какая из этих идей будет наиболее безопасной и удобной для пользователя? Или не адекватны?

---

Редактировать

Может ли переполнение стека помочь мне, оценив ответы? Ниже представлено несколько мнений, но SO не указывает на качество ответов.

Answer 1

В моих системах, когда кто-то запрашивает утерянный пароль, я:

1. Я генерирую GUID и сохраняю его в базе данных вместе с датой / временем запроса.
2. Отправьте пользователю ссылку с закодированным GUID, чтобы при нажатии на ссылку он связывал его с этим GUID
3. Убедитесь, что GUID / ссылка еще не «использовались».
4. Убедитесь, что запрос не старше 30 минут (в целях безопасности у них есть только небольшое время для использования ссылки активации - они знают об этом из сообщения на экране запроса пароля)

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

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

Answer 2

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

Вот пример, который я бы использовал:

1. Ссылка "Забытый пароль" отправляет пользователя на URL-адрес со встроенным UID
2. На странице "Забытый пароль" отправляется электронное письмо, содержащее код, который необходимо ввести на этой странице
3. Код действителен толькопри отправке с URL-адреса с правильным UID.
4. Если с действительного URL-адреса отправлен действительный код, пользователь отправляется по ссылке «Сбросить пароль».

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

Answer 3

Правила доступа к корпоративной сети и входа в систему могут отличаться от правил для веб-сайта или учетной записи, доступ к которой осуществляется из общедоступного Интернета.У вас может быть адрес электронной почты, а также часть номера сотрудника / персонала пользователей и пропуск безопасности или серийный номер карты, или вы можете использовать уникальный и конфиденциальный идентификатор входа, выданный службой поддержки ИТ каждому новому пользователю.

Answer 4

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