Регистрация пользователя (и аутентификация позже) - мой метод или использовать OpenID? - PullRequest
5 голосов
/ 05 июля 2011

Добрый день,

Я работаю над сценарием, позволяющим пользователям новостей регистрироваться на сайте.

В двух словах, я запланировал следующие шаги:

  1. register.php - Новый пользователь заполняет форму, вводя свое имя пользователя, детали адреса, название компании и адрес электронной почты. Затем данные отправляются обратно в сценарий через SSL.

  2. register.php - Сценарий проверяет, что имя пользователя или адрес электронной почты еще не сохранены в базе данных. Если это не так, он использует эти данные для создания токена, который отправляется по электронной почте на адрес электронной почты в виде гиперссылки, с этим токеном и остальными данными в качестве параметров гиперссылки. Используемый токен сделан из секретной строки - таким образом, только этот скрипт может создать код, который может быть восстановлен с использованием оставшихся данных.

  3. электронная почта - гиперссылка (SSL) нажимается, тем самым передавая данные через $ _GET в следующий скрипт через SSL.

  4. verify.php - токен восстанавливается с использованием переданных данных $ _GET и известной секретной строки. Если хеш идентичен, мы знаем, что токен был сгенерирован одним из наших скриптов. Пользователю предлагается ввести пароль (дважды), прежде чем нажать кнопку «отправить» (которая отправляет данные себе через SSL).

  5. verify.php - Сценарий проверяет, нет ли имени пользователя или адреса электронной почты, перед вставкой новых данных пользователя в базу данных, а также хешированного пароля и соли.

  6. электронная почта - Администратору отправляется уведомление по электронной почте о том, что он зарегистрировал нового пользователя. Прежде чем он сможет войти в систему, необходимо подтвердить его. Электронное письмо содержит ссылка на следующий скрипт с идентификатором нового пользователя, переданного ему через $ _GET. Используется SSL.

  7. verify.php - Скрипт использует переданный идентификатор нового пользователя для отображения всех зарегистрированных деталей в редактируемых полях (не пароль или соль). При нажатии «подтвердить» данные формы отправляются обратно в тот же сценарий через SSL.

  8. verify.php - Сценарий обновляет запись для этого пользователя и устанавливает для новой записи пользователя значение «подтверждено». Новый пользователь получает уведомление по электронной почте и может войти в систему.

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

Все новые пользователи должны подтвердить свой адрес электронной почты, прежде чем любые данные будут сохранены в нашей базе данных. Пароль не передается больше, чем нужно. Он передается в необработанном виде обратно в скрипт «verify.php» через POST, который затем хэширует его. Я буду следить за тем, чтобы данные POST для пакетов SSL не регистрировались на сервере. Таким образом, на сервере не должно быть записи необработанного пароля, верно?

Для каждого пользователя генерируется и сохраняется случайная соль - для защиты от радужных таблиц.

Я что-то пропустил? Мой единственный концерт - это передача необработанного пароля через SSL. Хотя SSL защищает от перехвата, мне все еще непросто получить необработанный пароль на сервере. Тем не менее, я не хочу делать проект уязвимым для атак среднего уровня, хэшируя его на стороне клиента.

Может кто-нибудь предложить какие-либо недостатки в моем методе? Я попробовал поискать в Google это, и хотя есть некоторые подходящие посты, кажется, ничто не связывает во всем процессе. Я надеюсь, что эта тема принесет пользу будущим посетителям этой страницы, а также мне.

Спасибо.

1 Ответ

2 голосов
/ 05 июля 2011

Я должен был сделать то же самое 2 месяца назад, и я сделал это по-вашему. За исключением этого пункта:

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

Достигнуто 2 цели: 1 - пользователи иногда боятся вводить много информации. Если они уже отправили свою электронную почту, они, как правило, более охотно продолжают процесс. 2- пользователи, которые уже зарегистрировались и находятся не на той странице: вы можете предположить, что они потеряли свою электронную почту, и предложить решение (если электронная почта уже есть в базе данных)

... но я лично считаю, что лучше всего придерживаться openId ;-) В следующий раз это то, что я попытаюсь использовать.

НТН

...