Что безопаснее? Должен ли я отправить электронное письмо с URL-адресом, срок действия которого истекает для пользователей, чтобы сбросить свой пароль, или я должен отправить по электронной почте новый пароль? - PullRequest
24 голосов
/ 17 февраля 2010

Мне было интересно, что будет безопаснее, когда пользователи забудут свой пароль

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

Или

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

Помимо того, что последний использует дополнительную таблицу, что, по вашему мнению, является более безопасной / лучшей практикой?

Ответы [ 14 ]

21 голосов
/ 17 февраля 2010

Если вы отправляете электронное письмо с паролем, это означает:

  • Пароль будет проходить через некоторые сети (в незашифрованном виде) и может быть «виден»
  • Пароль останется в почтовом ящике пользователя.
    • Который можно взломать
    • И любой, кто имеет доступ к компьютеру, может взглянуть

Итак, отправка пароля по электронной почте не кажется безопасной ...


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

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


Конечно, это означает, что я не смогу просто " поиск в моем почтовом ящике " найти пароль - но я всегда могу попросить новый, я снова забыл его ^^

10 голосов
/ 17 февраля 2010

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

Принудительное немедленное изменение пароля после использования ссылки / пароля и истечения срока действия ссылки / пароля через 24-72 часа.

8 голосов
/ 17 февраля 2010

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

Это определенно.

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

Помимо того, что последний использует дополнительную таблицу,

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

Пример использования кода аутентификации сообщений на основе HMAC (необычное хеширование):

details= user_id+' '+token_expiry_timestamp
mac= hmac_sha2(server_secret, details)
token= details+' '+mac

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

user_id, token_expiry_timestamp, mac= token split on ' '
details= user_id+' '+token_expiry_timestamp
if hmac_sha2(server_secret, details)!=mac
    complain
else if token_expiry_timestamp<now
    complain
else
    allow password for user_id to be changed

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

7 голосов
/ 17 февраля 2010

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

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

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

2 голосов
/ 17 февраля 2010

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

1 голос
/ 17 февраля 2010

Некоторые утверждают, что оба они эквивалентны - это неверно по следующим причинам:

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

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

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

Пара других вопросов:

Может ли ссылка использоваться несколько раз? Помимо истечения срока действия и наличия непредсказуемого значения (с подключенным MAC, чтобы его можно было проверить без состояния сервера), вы можете отключить внутреннее оповещение, если была предпринята попытка многократного сброса пароля для учетной записи (успешная / неудачная регистрация, удаленный IP-адрес, метка времени и т. д.) и прервать после первого и перевести учетную запись в неактивное состояние.

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

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

Как всегда, убедитесь, что ваши уведомления (текст, ссылка, целевая страница) не облегчают работу фишеров.

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

1 голос
/ 17 февраля 2010
  1. Отправьте им письмо со случайным одноразовым использованием, пароль.

  2. Заставить их изменить пароль при первом прибытии.

  3. Сообщите им, что они изменили свои пароль.

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

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

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

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

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

Ничто из этого не останавливает способность человека перехватывать электронную почту и получать НЕКОТОРЫЙ доступ, но по крайней мере это позволяет оригинальному, заинтересованному пользователю узнать, что что-то не так.

1 голос
/ 17 февраля 2010

Я всегда был фанатом установки хэш-кода и предоставления им ссылки.

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

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

К сожалению, нет настоящего "БЕЗОПАСНОГО" способа. Вопросы безопасности, которые могут помочь булавки, но они никогда не бывают действительно безопасными.

1 голос
/ 17 февраля 2010

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

Другими словами, ссылка уменьшает окно возможностей.

0 голосов
/ 17 февраля 2010

Расширение от решения bobince ... Здесь пользователю необходимо повторно ввести userId и токен на странице сброса пароля.

По запросу на страницу сброса пароля

urserId = Input userId
token = Randomly generated token (or one time password)
tokenExpire = Decide token expiry date/time
Store in DB tokenExpiry for this urserId
urlToken= MD5 hash value of (urserId + token + tokenExpire)
pwdRestURL = server pwd reset url + "?urlToken=" + urlToken

Send above generated URL and make sure you do not 
    include either of userId or token in email

Display token to user (This is to be used on password reset page)

.

На странице сброса пароля (используя вышеуказанный pwdRestURL URL)

urlToken = Token from URL request
userId = Input userId
token = Input token
tokenExpiry = tokenExpiry from DB for this user
resetToken = MD5 hash value of (urserId + token + tokenExpire)
IF
    resetToken == urlToken 
    AND tokenExpiry for user is valid
THEN
    Clear tokenExpiry
    Allow user to change password
ELSE
    Display Error
END IF

.

Преимущества вышеуказанного подхода:

  • Даже если электронная почта как-то разоблачена в сеть, никто не может сбросить пароль не зная userId и токена.
  • Токен имеет срок действия
  • Нет четкого теста личной информации ретранслируется по электронной почте
Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...