Использование автоматически сгенерированного URL-адреса в качестве пароля - PullRequest
1 голос
/ 28 марта 2011

Предположим, я хочу, чтобы посетители моего сайта могли заполнить длинную форму. Им не обязательно заполнять его, чтобы использовать сайт, но если они хотят отправить мне историю, они должны заполнить ее. Поэтому некоторые из них захотят это сделать, некоторые - нет. Форма довольно большая, поэтому посетитель может захотеть оставить ее наполовину заполненной, чтобы вернуться позже и закончить ее. Чтобы сделать процесс максимально простым для посетителя, я хочу, чтобы он просто щелкнул ссылку «Создать историю», которая перенаправит посетителя на автоматически сгенерированный URL-адрес, например www.mysurveys.com / 7Bs3h4vSWEe, Здесь посетитель работает со своей формой и нажимает «Сохранить», когда хочет сохранить ее, чтобы вернуться позже, чтобы завершить ее. Данные формы хранятся в базе данных со сгенерированным идентификатором. Когда посетитель считает, что форма заполнена правильно и заполнена, он нажимает кнопку «Отправить на проверку», а затем форма переходит ко мне.

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

Ответы [ 2 ]

1 голос
/ 29 марта 2011

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

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

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

1 голос
/ 28 марта 2011

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

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

...