@GoldFox2015

Как реализовать грамотную авторизацию PHP?

Встал серьёзный вопрос о защите при авторизации. На данный момент накидал такой скелет авторизации:

1. После нажатия на кнопку авторизации создаём сессию и куки.
2. В сессию заносим id пользователя, в куки заносим специально сгенерированный хэш и id пользователя.
3. Далее сохраняем хэш в базе данных.
4. После авторизации сверяем хэш по базе и id из сессии, если они равны = даём доступ. Если id не подходит к хэшу или хэш к id, тогда доступ не даём.


Правильная-ли такая реализация?
  • Вопрос задан
  • 690 просмотров
Пригласить эксперта
Ответы на вопрос 3
@andreyk0
Можно хранит в куки id, зону юзера, сам пароль зашифров необратим шифрование с солью и ip так же в этом же формате. При обращении к любой страницы получаешь все что необходимо. При смене ip чистиш кэш и кидаешь на логин форму. ☕
Ответ написан
Комментировать
@alpeg
Грамотная авторизация делается вот как:
Генерируем токен, ставим его пользователю в кукисы и пишем его в базу. Когда пришел запрос, проверяем, активен ли токен, и не протух ли, если всё ок, даём доступ, нет - шлём на авторизацию.
Сессия для этого кстати необязательна. А, ну ещё второй токен, для CSRF. его тоже просто в кукисы.
и там и там кукисы secure + httpOnly.
Всё остальное - вариации на тему. Свои велосипеды городить не рекомендуется ввиду того, что они всегда приводят к дырам.

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

Специально сгенерированный хэш - плохая идея, только абсолютно рандомный токен.
Шифровать пароль и прочее в куку - очень плохая идея, забудьте.
Шифровать userid и права - только в виде JWT, свой велосипед не городить, вечных и долгих токенов не давать (пусть обновляют, это обязательно).
Ответ написан
Stalker_RED
@Stalker_RED
1. После нажатия на кнопку авторизации создаём сессию и куки.
можно сессию и раньше создавать

2. В сессию заносим id пользователя
ок

... в куки заносим специально сгенерированный хэш и id пользователя.

зачем? Лишняя потенциальная уязвимость.
3. Далее сохраняем хэш в базе данных.
Зачем?

4. После авторизации сверяем хэш по базе и id из сессии, если они равны = даём доступ. Если id не подходит к хэшу или хэш к id, тогда доступ не даём.
Зачем сравнивать? Предполагается, что злоумышленник хозяйничает у вас на сервере, и меняет данные в сессиях?
Ответ написан
Комментировать
Ваш ответ на вопрос

Войдите, чтобы написать ответ

Войти через центр авторизации
Похожие вопросы