Мгновенный вход с электронной почты. Почему так мало сделано?

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

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

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

Перед отправкой напоминания электронной почте Джону Доу, сгенерируйте токен случайного числа (достаточно большое количество, чтобы предотвратить угадывание), срок действия которого истекает через несколько дней.
В электронном письме укажите URL-адрес, содержащий хешированную форму токена (perhap xor с идентификатором пользователя).
Когда Джон Доу входит в свой адрес электронной почты и нажимает на ссылку, сервер проверяет наличие токена в БД и что он не истек. Если токен существует, он автоматически регистрируется сервером.

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

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

Ответ 1

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

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

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

Ответ 2

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

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

Пароль reset по электронной почте обычно (надеюсь,?) требует второго фактора - секретного вопроса.
У вас не будет вопроса безопасности.

Ответ 3

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

Ответ 4

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

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

Ответ 5

У Lea Verou есть интересная идея:

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

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

Ответ 6

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

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

Ответ 7

Как вы знаете, так работает сбрасывание пароля (в основном). Почему бы не войти так? Потому что вы в основном помещаете имя пользователя и пароль в текст в строке запроса, что плохо. Смотрите: Безопасна ли строка запроса HTTPS?

Ответ 8

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

Ответ 9

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

Ответ 10

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

Вспомним, что для механизмов паролей reset достаточно распространено (и неаккуратно) для сочетания с одним или несколькими из следующих элементов:

Обнаружение подозрительной активности. Без этого нельзя отрицать, что вы создаете системы аутентификации любителя (возможно, такая работа для более способных людей?). Например. это пароль reset, исходящий из страны, где Пользователь обычно использует систему? Были ли несколько неудачных попыток входа в учетную запись (или какие-либо учетные записи недавно) (словарные атаки, бот-сети и т.д.)? Вероятно, что механизмы reset для паролей, которые вы использовали и оценивали при формулировании ваших решений, были фактически (под поверхностью), используя определенную форму обнаружения подозрительной активности.
Вопросы безопасности. https://www.owasp.org/index.php/Choosing_and_Using_Security_Questions_Cheat_Sheet

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

Ответ 11

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