Каковы наилучшие методы для активации/регистрации/пароля- reset ссылок в сообщениях электронной почты с помощью nonce

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

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

  • Ссылка содержит nonce в URI запроса (http://host/path?nonce).
  • По ссылке (GET) пользователю предоставляется форма, необязательно с номером.
  • Пользователь подтверждает ввод (POST).
  • Сервер получает запрос и
    • проверяет входные параметры,
    • выполняет изменение,
    • и делает недействительным значение nonce.

Это должно быть правильно для HTTP RFC по безопасным и идемпотентным методам.

Проблема заключается в том, что этот процесс включает в себя одну дополнительную страницу или действие пользователя (пункт 3), которое считается излишним (если не бесполезным) для многих людей. У меня возникли проблемы с представлением такого подхода для сверстников и клиентов, поэтому я прошу внести свой вклад в эту более широкую техническую группу. Единственный аргумент, который я имел против пропустить шаг POST, - это возможная предварительная загрузка ссылки из браузера.

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

Спасибо,
Kariem

Детали, сохраненные

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

  • Содержание сообщения не является частью этого обсуждения. Пользователь знает, что ей нужно щелкнуть ссылку, чтобы выполнить действие. Если пользователь не реагирует, ничего не произойдет, что также известно.
  • Нам не нужно указывать, почему мы отправляем по почте пользователя, а также политику связи. Мы предполагаем, что пользователь ожидает получить электронное письмо.
  • У nonce есть временная метка истечения срока действия и напрямую связана с адресом электронной почты получателей, чтобы уменьшить дубликаты.

Примечания

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

Как ни странно, я еще не нашел удовлетворительного вопроса и ответа. Что я нашел до сих пор:

Ответы

Ответ 1

Этот вопрос очень похож на Внедрение безопасных уникальных URL-адресов для однократного использования в ASP.NET(С#).

Мой ответ рядом с вашей схемой, с несколькими указанными вопросами - например, короткий срок действия, обработка двойных регистраций и т.д.
Важное значение имеет использование использования криптографического nonce, что многие, как правило, пропускают - например, "позволяет просто использовать GUID"...

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

Мне хотелось бы сказать, что это действительно не нарушает идемпотентность GET, но, к сожалению, это так... С другой стороны, RFC говорит, что GET СЛЕДУЕТ быть идемпотентным, его не ДОЛЖЕН. Поэтому я бы сказал, откажись от этого в этом случае, и придерживайтесь одноразовых авто-недействительных ссылок.

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

Вам не нужно беспокоиться о предварительной загрузке (вы говорите о CSRF или оптимизаторах браузера?)... CSRF бесполезен из-за nonce, а оптимизаторы обычно не обрабатывают javascript (используемый для автоматической отправки) на предварительно загруженная страница.

Ответ 2

О пароле reset:

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

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

Я нашел этот белый документ, в котором обсуждается тема.

Краткая версия того, как это сделать безопасным способом:

  • Требовать жесткие факты об учетной записи

    • имя пользователя.
    • адрес электронной почты.
    • 10-значный номер счета или другая информация как номер социального страхования.

  • Требовать, чтобы пользователь отвечал как минимум на три предопределенных вопроса (предопределенные вами, не позволяйте пользователю создавать свои собственные вопросы), которые не могут быть тривиальными. Как "Что ваше любимое место отдыха ", а не" Какой ваш любимый цвет ".

  • Необязательно: отправьте код подтверждения на предопределенный адрес электронной почты или номер ячейки (SMS), который должен ввести пользователь.

  • Разрешить пользователю вводить новый пароль.

Ответ 3

Я вообще согласен с вами с некоторыми изменениями, предложенными ниже.

  • Пользователь регистрируется на вашем сайте, предоставляя электронное письмо.
  • Адрес электронной почты проверки отправляется на учетную запись пользователя с двумя ссылками: a) Одна ссылка с GUID для проверки регистрации. b) Одна ссылка с GUID для отклонения проверки.
  • Когда они посещают URL-адрес проверки по электронной почте, они автоматически проверяются, и руководство по проверке помечено как таковое в вашей системе.
  • Когда они посещают URL-адрес отклонения по электронной почте, они автоматически удаляются из очереди возможных проверок, но, что более важно, вы можете сообщить пользователю, что вы сожалеете о регистрации по электронной почте, и дайте им дополнительные варианты, такие как удаление их электронной почты с вашего система. Это остановит любые жалобы типа персонализированного типа о том, кто входит в мою электронную почту в вашей системе... blah blah blah.

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