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

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

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

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

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

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

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

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

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

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

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

нет никаких проблем вообще с параметрами в a HTTPS-запрос, кстати.

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

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

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

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

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

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

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

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

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

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

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

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

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