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

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

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

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

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

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

Что вы думаете об этом? Достаточно ли это безопасно? Что бы вы посоветовали мне для генерации токенов? А как насчет передачи параметров URL в запросе https?

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

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

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

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

На мой взгляд, это плохая идея.

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

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

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

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

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

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

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

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

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

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

Между прочим, никаких проблем с параметрами в https-запросе нет.

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

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

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

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

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

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

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

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

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

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

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

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

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