Каковы наилучшие методы для активации/регистрации/пароля- 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.

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