Https URL с параметром token: насколько он безопасен?

На нашем сайте мы предоставляем пользователям симуляцию, основанную на их личной информации (предоставляемой через форму). Мы хотели бы позволить им вернуться к результатам имитации позже, но не заставляя их создавать учетную запись для входа/пароля.

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

Итак, мы намерены передать токен (например, комбинацию букв и цифр из 40 символов или хеш файл MD5) в URL-адресе и использовать SSL.

Наконец, они получили бы такое электронное письмо:

Привет,
Верните результаты https://www.example.com/load_simulation?token=uZVTLBCWcw33RIhvnbxTKxTxM2rKJ7YJrwyUXhXn

Что вы думаете об этом? Это достаточно безопасно? Что бы вы посоветовали мне за создание маркера? Как насчет передачи параметров URL в запросе https?

Ответ 1

SSL будет защищать параметры запроса в пути; однако сам адрес электронной почты не является безопасным, и письмо может отскакивать на любом количестве серверов, прежде чем добраться до места назначения.

Кроме того, в зависимости от вашего веб-сервера полный URL-адрес может регистрироваться в файлах журнала. В зависимости от того, насколько чувствительны данные, вы, возможно, не хотите, чтобы ваши ИТ-специалисты имели доступ ко всем токенам.

Кроме того, URL-адрес с строкой запроса будет сохранен в истории пользователя, что позволит другим пользователям одного и того же компьютера получить доступ к URL-адресу.

Наконец, и что делает это очень небезопасным, URL-адрес отправляется в заголовке Referer всех запросов для любого ресурса, даже сторонних ресурсов. Поэтому, если вы используете Google Analytics, например, вы отправите Google токен URL-адресов для них.

По-моему, это плохая идея.

Ответ 2

Я бы использовал для этого файл cookie. Рабочий процесс должен выглядеть следующим образом:

Пользователь впервые приходит на ваш сайт.
Сайт устанавливает cookie
Пользователь вводит данные. Данные хранятся в БД с использованием некоторого ключа, который хранится в файле cookie.
Когда пользователь уходит, вы отправляете им электронное письмо с https: link
Когда пользователь возвращается, сайт обнаруживает куки файл и может представить пользователю старые данные.

Теперь пользователь хочет использовать другой браузер на другой машине. В этом случае предложите кнопку "передача". Когда пользователь нажимает на эту кнопку, она получит "токен". Она может использовать этот токен на другом компьютере для reset cookie. Таким образом, пользователь решает, насколько безопасно она хочет передать токен.

Ответ 3

SSL защищает содержимое данных в пути, но я не уверен в URL.

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

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

Ответ 4

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

Ответ 5

Ну, токен защищен при передаче через SSL. Проблема, с которой вы столкнетесь, заключается в том, что она доступна людям (тем, для кого она не предназначена), имея возможность просматривать URL-адрес.

Если это частная информация, такая как SSN, я не думаю, что отправлю URL-адрес по электронной почте. Я предпочел бы, чтобы они создали имя пользователя и пароль для сайта. Слишком легко скомпрометировать электронную почту с такой информацией, которую вы поставили перед собой и для них. Если какая-то учетная запись будет включена, она войдет в вопрос, чья вина на самом деле. Чем безопаснее, тем лучше вы со стороны строго CYA.

Ответ 6

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

Нет никаких проблем с параметрами в запросе https, кстати.

Ответ 7

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

Лучше всего было бы использовать имя пользователя и пароль для доступа к информации.

Мне нравится идея cookie более или менее. Вы также должны шифровать информацию о файлах cookie. Вы также должны генерировать токен с солью и ключевой фразой плюс $_SERVER ['HTTP_USER_AGENT'], чтобы ограничить вероятность атаки. Храните как можно больше информации о клиенте в файле cookie для проверки использования.

Ключевая фраза может быть сохранена в файле cookie для удобства использования, но имейте в виду, что cookie можно украсть = (.

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

Или ключ можно использовать, если человек использует другую машину, которая отличается параметрами $_SERVER ['HTTP_USER_AGENT'] или просто пропускает файл cookie. Таким образом, cookie может быть передан или установлен.

Также убедитесь, что конфиденциальные данные зашифрованы в базе данных. Вы никогда не знаете;)

Ответ 8

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

После этого я бы сказал, что это не плохо, как идея. Я бы не использовал MD5 или SHA1, поскольку они не очень безопасны для хэширования. Они могут быть "дешифрованы" (я знаю, что это не шифрование) довольно легко.

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

Обратите внимание, что HTTPS будет защищать и шифровать данные, отправленные с вашего сайта конечному пользователю. Ничто другое не воспринимается как безопасный. Больше ничего не значит.

Ответ 9

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

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