Что является лучшими практиками для ссылок активации/регистрации/сброса пароля в электронных письмах с данным случаем
Поскольку никто не поделился аккуратными двумя вкладышами, я поделюсь своим:
logging.basicConfig(filename='logs.log', level=logging.DEBUG, format="%(asctime)s:%(levelname)s: %(message)s")
logging.getLogger().addHandler(logging.StreamHandler())
3 ответа
Этот вопрос очень похож на Реализация безопасных, уникальных "одноразовых" URL-адресов активации в ASP.NET (C #) .
Мой ответ близок к вашей схеме с указанием нескольких проблем, таких как короткий период действия, обработка двойных подписок и т. Д.
Также важно использование вами криптографического одноразового номера, который многие пропускают - например, «давайте просто используем GUID» ...
Один новый момент, который вы поднимаете, и это важно здесь , относится к идемпотентности GET.
Хотя я согласен с вашим общим намерением, ясно, что идемпотентность находится в прямом противоречии с одноразовыми ссылками, что необходимо в некоторых ситуациях, подобных этой.
Я хотел бы заявить, что это на самом деле не нарушает идемпотентность GET, но, к сожалению, это так ... С другой стороны, RFC говорит, что GET ДОЛЖЕН быть идемпотентным, а не обязательно. Поэтому я бы посоветовал отказаться от этого в данном случае и придерживаться одноразовых автоматически аннулированных ссылок.
Если вы действительно хотите стремиться к строгому соответствию RFC, а не попадать в неидемпотентные ( ?) GETs, у вас может быть страница GET, которая автоматически отправляет POST - своего рода лазейка вокруг этого фрагмента RFC, но законная, и вы не требуете, чтобы пользователь дважды соглашался, и вы не беспокоите его .. .
Я в целом согласен с вами с некоторыми изменениями, предложенными ниже.
- Пользователь регистрируется на вашем сайте, отправляя письмо по электронной почте.
- Письмо с подтверждением отправляется на учетную запись пользователя с двумя ссылками: a) Одна ссылка с GUID для проверки регистрации b) Одна ссылка с GUID для отклонения проверки
- Когда они посещают URL-адрес подтверждения из своего электронного письма, они автоматически проверяются, и руководство проверки отмечается как таковое в вашей системе.
- Когда они посещают URL-адрес отклонения в своем электронном письме, они автоматически удаляются из очереди возможных проверок, но, что более важно, вы можете сказать пользователю, что вы сожалеете о регистрации электронной почты, и предоставить им дополнительные возможности, такие как удаление его электронной почты из вашей система. Это остановит любые жалобы на тип настраиваемой службы о том, что кто-то вводит мой адрес электронной почты в вашу систему ... бла-бла-бла.
Да, вы должны предполагать, что когда они щелкают ссылку подтверждения, они проверяются. Заставить их нажать вторую кнопку на странице - это немного и требуется только для двойной регистрации стиля, когда вы планируете рассылать спам зарегистрировавшемуся человеку. Стандартные схемы регистрации / проверки обычно этого не требуют.
О сбросе пароля:
Практика выполнения этого путем отправки электронного письма на зарегистрированный адрес электронной почты пользователя, хотя и очень распространена на практике, не является хорошей безопасностью. При этом безопасность вашего приложения полностью передается поставщику электронной почты пользователя. Не имеет значения, какой длины вам нужны пароли и какое умное хеширование паролей вы используете. Я смогу попасть на ваш сайт, прочитав электронное письмо, отправленное пользователю, при условии, что у меня есть доступ к учетной записи электронной почты или я могу читать незашифрованное письмо в любом месте на пути к пользователю (подумайте: злые системные администраторы).
Это может быть или не быть важным в зависимости от требований безопасности рассматриваемого сайта, но я, как пользователь сайта, по крайней мере, хотел бы иметь возможность отключить такую функцию сброса пароля, поскольку считаю ее небезопасной. . например, номер социального страхования.
Требовать, чтобы пользователь ответил как минимум на три заранее заданных вопроса (заданных вами, не позволяйте пользователю создавать свои собственные вопросы), что не может быть тривиальным. Как "Что ваше любимое место для отпуска ", а не" Какой ваш любимый цвет ".
При желании: отправьте код подтверждения на заранее определенный адрес электронной почты или номер ячейки (SMS), который пользователь должен ввести.
Разрешите пользователю ввести новый пароль.