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

Question

[GoldFox2015]

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

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

Правильная-ли такая реализация?

Comments

[d'Ivan]

Здесь путаница в терминах. Почитайте https://habr.com/ru/company/avanpost/blog/480576/

Answer 1

[Андрей]

Можно хранит в куки id, зону юзера, сам пароль зашифров необратим шифрование с солью и ip так же в этом же формате. При обращении к любой страницы получаешь все что необходимо. При смене ip чистиш кэш и кидаешь на логин форму. ☕

Answer 2

[alpeg]

Грамотная авторизация делается вот как:
Генерируем токен, ставим его пользователю в кукисы и пишем его в базу. Когда пришел запрос, проверяем, активен ли токен, и не протух ли, если всё ок, даём доступ, нет - шлём на авторизацию.
Сессия для этого кстати необязательна. А, ну ещё второй токен, для CSRF. его тоже просто в кукисы.
и там и там кукисы secure + httpOnly.
Всё остальное - вариации на тему. Свои велосипеды городить не рекомендуется ввиду того, что они всегда приводят к дырам.

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

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

Comments

[GoldFox2015]

Ну а если в сессию записать id пользователя полученный при авторизации, и далее работать только с ним, со стороны безопасности это нормально?

[alpeg]

Ну а если в сессию записать id пользователя полученный при авторизации, и далее работать только с ним, со стороны безопасности это нормально?

GoldFox2015, нормально (и хорошо с точки зрения уменьшения запросов к базе), но надо иметь возможность следить за такими пользователями и обрубать их в случае необходимости (ведь сессию при должном умении можно держать вечно).
Т.е. по хорошему надо в сессию также писать таймаут, по истечении которого скрипт будет лезть в базу и смотреть, не протух ли пользователь и его права доступа, не хочет ли пользователь разлогинить все сессии и т.п.

Фактически такой подход отличается от "основного" (токены в базе) только тем, что вместо токена хранящегося в базе, токеном служит ид сессии, по которому на сервере хранится связть "ид сессии -> ид пользователя"

[alpeg]

ubuntu_lts, непонятно, зачем тогда вообще сессия, токен можно и в куки записать.
Кроме этого, это не даст зайти с нескольких устройств, правильно будет делать отдельно таблицу "токен-айди пользователя-время последней активности-время протухания"

[alpeg]

не нужна такая запутанная дичь )))

ubuntu_lts, у вас только одно устройство? никогда не заходили с нескольких в один аккаунт?
И в вашем случае сессия-то зачем, токен можно в кукисы записать с таким же успехом.

Answer 3

[Stalker_RED]

1. После нажатия на кнопку авторизации создаём сессию и куки.

можно сессию и раньше создавать

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

ок

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

зачем? Лишняя потенциальная уязвимость.

3. Далее сохраняем хэш в базе данных.

Зачем?

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

Зачем сравнивать? Предполагается, что злоумышленник хозяйничает у вас на сервере, и меняет данные в сессиях?