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

Question

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

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

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

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

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

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

Answer 1

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

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

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

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

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

Answer 2

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

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

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

Answer 3

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

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

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

Answer 4

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

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

Answer 5

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

Answer 6

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

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

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

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

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

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

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

Answer 7

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

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

Answer 8

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

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

Answer 9

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

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

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

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