security - теги - Проблемы безопасности в отношении имени пользователя/пароля и секретного URL




парсер заголовков php (4)

У меня есть простой сайт с формой регистрации. В настоящее время пользователь может дополнить свою регистрацию с помощью (некритической, «низкой безопасности») информации, недоступной на момент регистрации, посредством личного (секретного) URL-адреса.

Т.е., как только они нажимают кнопку submit, они получают сообщение типа:

Спасибо за регистрацию. Вы можете дополнить свою регистрацию, добавив информацию через этот персональный URL:

http://www.example.com/extra_info/cwm8iue2gi

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

Мой вопрос: Существуют ли какие-либо проблемы с безопасностью с использованием секретного URL вместо полной системы имени пользователя и пароля?

Единственное, что я могу придумать, это то, что URL-адреса хранятся в истории браузера. Меня это не волнует. Я что-то упускаю?

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


могут дополнять их регистрацию (некритическая, «низкая безопасность») информации

Трудно представить, какая информация, предоставляемая пользователем, действительно является «низкой безопасностью»; даже если вы запрашиваете пароль и имя пользователя от своих клиентов, вы потихоньку нарушаете обязанность заботиться о своих клиентах; большое количество пользователей будет использовать одно и то же имя пользователя / пароль на нескольких сайтах. Любая информация о ваших пользователях и потенциальная информация о транзакциях может использоваться третьей стороной для компрометации личности этого пользователя.

Любая информация о пользователе должна быть предоставлена ​​в формате enctypted (например, через https). И вы должны принять соответствующие меры для защиты хранящихся данных (например, хеширование паролей).

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

C.


Другая потенциальная проблема заключается в самих пользователях. Большинство людей понимают, что пароль - это то, что они должны пытаться защитить. Однако, сколько пользователей, вероятно, узнают, что они должны предпринять какие-то усилия для защиты вашего секретного URL-адреса?


Секретный URL-адрес ничего не значит, если вы не используете SSL. Если у вас все еще есть конечный пользователь, передающий свою идентифицирующую информацию через Интернет в ясном виде, то не имеет значения, как вы их впускаете: они все еще открыты.


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

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

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







password-protection