Как всё-таки правильно сделать аутентификацию на php?

Question

[Станислав Некрасов]

[]

Здравствуйте. С наступающим Новым Годом всех.
Насчёт вопроса, да, таких вопросов было много, статей тоже много... В общем всё это смешалось и не знаю теперь как правильно сделать.
Использовать фреймворки, CMS и т. п. не планируется.

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

Так вот, я думаю как это лучше сделать..

Пользователь вводит почту (Логин) и пароль. В базе данных ищется такой логин, с помощью password_verify() проверяется пароль и если всё правильно, то в сессию записывается id пользователя, а в куки записывается token (Который создаётся и записывается также в БД). После всё время берётся id пользователя с сессии, а когда сессия новая, то из куки берётся этот токен (если он есть) и по нему находится в БД id пользователя и записывается в сессию... (А токен наверное можно пересоздавать?)
Мне кажется, что этот способ небезопасный... Если украсть токен, то можно получить доступ к аккаунту пользователя.. И также с id сессии...

Как правильнее это делать, чтобы это было более менее безопасно? Возможно, всё вообще по-другому надо сделать?

Answer 1

[OnlyMyQuestion]

Собственно, сессия также - подвержена данным проблемам, ее id также хранится в cookie.
В большинстве случаев - используются цифровые отпечатки. Если человек зашел из Китая, при постоянном посещении из РФ - будет подозрительно, сюда же можно отнести проверку user-agent. По сути - идеального решения не существует, ну, или я недостаточно осведомлен.
JWT - если украсть access токен, то какое-то время он будет валиден, если хранить, все в бд - смысл jwt исчезает.
OAuth - украл токен, можно использовать.
Все сводится к дополнительной верификации по косвенным параметрам.

Comments

[Станислав Некрасов]

Т.е. для начала в принципе мой способ нормальный? А потом уже можно будет переделать, если что? И кстати, не знаете, $_SERVER['REMOTE_ADDR'] клиент может сам подделать, т.е. может ли он содержать что-то отличное от ip адреса?

[OnlyMyQuestion]

Нет, REMOTE_ADDR не может подделаться клиентом в явном виде. Для подделывания использывается "IP-спуфинг", но ответ не придет атакующему в прямом виде, а отправиться на поддельный IP, есть варианты обхода и данного ограничения, но все это сложно и описать парой строк невозможно. Если используется proxy, то в данном поле будет находиться ip proxy сервера, а реальный ip клиента будет в HTTP_X_FORWARDED_FOR, или подобном ключе. Если рассмотреть в данном контексте обработку безопасности REMOTE_ADDR достаточно безопасен, в отличии от HTTP_* ключей, которые на деле являются заголовками запроса и легко могут быть подделаны клиентом.
В REMOTE_ADDR, может находится и адрес клиента, при работе через proxy, но данная настройка происходит на сервере, пример:
Пускаем трафик через cloudflare, в nginx для масок cloudflare, ставит настройку для замены REMOTE_ADDR на X_FORWARDED_FOR.
Технически - REMOTE_ADDR подделан, но он верный, так как cloudflare не пропустит поддельный заголовок X_FORWARDED_FOR, а назначит его сам.

[Станислав Некрасов]

OnlyMyQuestion, хорошо, спасибо)

Answer 2

[xmoonlight]

Кратко, цепочка связей:
Аккаунт(форма авторизации/логин)->Устройство(fingerprint)->Токен(ссылка через почту)->Пользователь.