Мгновенный вход из электронной почты.Почему так мало сделали это? - PullRequest
39 голосов
/ 11 января 2011

Пробовал искать это, но ничего не получилось.Запрашиваются обсуждения или соответствующие ссылки.

Предположим, что мы собираемся отправить электронное письмо, чтобы побудить пользователя войти в наше супер-социальное веб-приложение.Цель этого письма - заставить их вернуться на сайт и побродить еще немного, прежде чем они забудут нас, поэтому, естественно, мы хотим снизить барьер для их возвращения.Файлы cookie помогают избежать необходимости входить в систему каждый раз, но не помогают в случае, когда пользователь забыл свои учетные данные.Мы хотим мгновенного удовлетворения здесь - одним щелчком мыши прямо к действию ребенка.Вместо этого, почему мы не можем просто отправить пользователю хешированную форму случайно сгенерированного, чувствительного ко времени токена, который мы сохранили в БД?Если они могут предоставить этот токен обратно на сервер, то мы можем доверять их личности.

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

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

  2. В письме укажите URL-адрес, содержащий хешированную форму токена (perhap xor с идентификатором пользователя).

  3. Когда ДжонDoe входит в свою электронную почту и нажимает на ссылку, сервер проверяет наличие токена в БД и его срок действия не истек.Если токен существует, он автоматически регистрируется сервером.

Безопасность: мы предполагаем, что электронная почта для Джона Доу действительно принадлежит Джону Доу, хотя бы потому, что адреса электронной почты проверены какчасть процесса регистрации.Любой пользователь, имеющий доступ к электронной почте Джона Доу, сможет получить доступ к своей учетной записи;Однако это не ново.Многие сайты уже предполагают, что учетная запись электронной почты пользователя является безопасной, поскольку они реализуют функцию сброса пароля на электронную почту.

Мой поисковый запрос обнаружил только один сайт, который делает это, OKCupid, который является сайтом онлайн-знакомств.Кто-нибудь знает какие-либо другие сайты, которые делают это?Почему мгновенный вход по электронной почте более распространен?Безопасность?Отсутствие существенной выгоды для дополнительной сложности?

Ответы [ 11 ]

11 голосов
/ 11 января 2011

На некоторых сайтах вы можете отделить «важные вещи» от «действительно очень важных вещей».Допустим, что «важные вещи» на вашем сайте позволяют пользователям просматривать политики, активных участников и входящие групповые сообщения.«Действительно, действительно важные вещи» позволяют вам изменять политики, сбрасывать пароли и добавлять новых пользователей.Итак, вы можете сделать следующее:

  1. Разрешите вашей http-ссылке дать доступ к "важным вещам".В конце концов, это не конец света, если люди знают о политиках, пользователях или сообщениях в вашей системе.
  2. Запросите подлинную аутентификацию по имени пользователя / паролю, если сделан запрос на «действительно очень важные вещи».

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

9 голосов
/ 11 января 2011

Письма не защищены.

Вы не можете предполагать, что электронная почта не будет видна в пути, и вы также не можете предполагать, что пользователь будет читать электронную почту по SSL (особенно если он использует клиент веб-почты)

Для сброса пароля по электронной почте обычно (надеюсь?) Требуется второй фактор - секретный вопрос.
У вас не будет секретного вопроса.

7 голосов
/ 21 августа 2013

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

4 голосов
/ 11 января 2011

Многие веб-сайты позволяют пользователям восстанавливать свои пароли посредством проверки электронной почты. Ваша идея не сильно отличается, но:

  1. Если пользователь не входит на ваш сайт, перейдя по ссылке в SSL, то ваш ключ передается в незашифрованном виде и может быть взломан с помощью перехвата пакетов.
  2. Вы сказали, что сгенерированный токен истекает через несколько дней. Долгое время истечения сделает вас более уязвимыми для захвата сессии. Срок действия токенов, созданных для восстановления пароля, обычно составляет менее часа.
3 голосов
/ 14 февраля 2014

У Леа Веру есть интересная идея:

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

Источник: http://lea.verou.me/2010/08/automatic-login-via-notification-emails/

2 голосов
/ 29 августа 2017

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

1 голос
/ 26 октября 2016

Учитывая, что "сброс пароля" в этом потоке делает одно и то же:

Напомним, что довольно часто (и небрежно, чтобы) механизмы сброса пароля объединялись с одним илибольше из следующего:

  • Обнаружение подозрительной активности .Без этого нельзя отрицать, что вы создаете любительские системы аутентификации (возможно, оставьте такую ​​работу более способным людям?).Например, сброс пароля происходит из страны, где пользователь обычно использует систему?Было ли несколько неудачных попыток войти в учетную запись (или какие-либо учетные записи в последнее время) (словарные атаки, бот-сети и т. Д.)?Вполне вероятно, что механизмы сброса пароля, которые вы использовали и оценивали при формулировании своих решений, фактически (под поверхностью) использовали некоторую форму обнаружения подозрительной активности.

  • Безопасностьвопрос (ы) .https://www.owasp.org/index.php/Choosing_and_Using_Security_Questions_Cheat_Sheet

Ради любви к Богу, люди, пожалуйста, внимательно прочитайте это: https://www.owasp.org/index.php/Forgot_Password_Cheat_Sheet

1 голос
/ 11 января 2011

Я подозреваю, что лучшей идеей было бы разрешить вход в систему с использованием OpenID / OAuth. Тогда пользователям не нужно запоминать или вводить пароль для вашего сайта ни при каких обстоятельствах, поэтому приходите с «вернись!» электронная почта не отличается от любого другого маршрута.

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

1 голос
/ 11 января 2011

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

1 голос
/ 11 января 2011

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

...