Как лучше сделать? Меняется ли с каждым годом технология? Все руководства, найденные в гугле, устарели.

Создается хранилище пользовательских данных. Там - id, login, hash, salt.

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

из чего такой вывод?

1. Датируются руководства 1999-2005 годами, короче 10+ лет назад
2. Мой склад психики такой, что я крайностями воспринимаю все...  (врожденно)

Добавлено через 1 минуту и 49 секунд
Aliance, если все так просто. Тогда почему я лет 7 назад читал, что типа IPB форум развивается к примеру, и все равно все новые и новые способы взлома (причем массового) и новые и новые заплатки. Самописная рукопись(движок) ведь еще хуже будет? :(

Это сообщение отредактировал(а) Win MK 32 - 10.6.2014, 09:44

IBP тоже не богами писана


это не взлом аутентификации. в основном sql инъекции, обход системы аутентификации, ошибки в настройках сайта etc

посмотри на какую-нить современную реализацию, напр. Zend\Authentication
ничего принципиально нового по сравнению с тем, что написал Aliance.
только этого мало, еще надо грамотно применить: обеспечить правильный доступ к хранилищу, недоступность файлов проекта и т.д. в фреймворках это обеспечивается слоем доступа к БД/LDAP, продуманной файловой структурой и пр.

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

Если вам на процедурном php надо тогда и 10-летней давности смело можете брать, если на ООП тогда да ищите под версию от 5.0

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

А я не знаю как. Руки опускаются(

Это все перделки-свистелки, сам механизм будет работать и без них. А их можно накручивать потом сверху.


Здесь-то чего сложного? Берем логин, перед самим созданием пользователя проверяем наличие такого аккаунта в хранилище. если есть - выводим ошибку. Что тут конкретного-то не понятно?


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


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