Какой самый лёгкий и безопасный способ держать пользователя авторизованным?

Question

[Константин]

Поискав некоторые решения в интернете, понял что вполне можно через сессии реализовать такую функцию, но вот незадача - по умолчанию сессия 24 минуты, менять php.ini на другое значение - не вариант т.к. есть вероятность что в процессе разработки придётся также использовать сессии, но с другой длительностью. ini_set почти по той же причине отлетает из вариантов.

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

Хранить IP последнего входа в аккаунт? Идея неплохая, но если каким-то магическим образом БД взломают, то все айпи попадут нехорошим людям.

Вопрос остаётся - как реализовать нормальный и безопасный способ для такой функции, чтобы больше не приходилось использовать другие варианты после каждой очередной жалобы на взлом?

Comments

[Ипатьев]

потому что куки могут украсть.

Я вам открою стрррашную тайну: сессии для своей работы используют куки. Так что вам надо определиться - либо признать сессии тоже ужасно небезопасными, либо как-то смириться уже

[Дмитрий]

любой вариант авторизации предполагает выдачу пользователю чего либо такого что он потом сможет предъявлять на проходной что бы пропустили. И это чего нибудь такое - всегда можно стырить, и никакая надпись "никому не говорить этот код, даже сотрудникам банка" не спасет. Собственно ровно по этому львиная доля всех взломов - это социальная инженерия.

[Antonio Solo]

Дмитрий, не любой

например можно использовать клиентские SSL сертификаты а их хранить на защищенном хранилище

[Antonio Solo]

У вас реально есть что ворровать на сайте? C вероянтостью 99% на вашем сайте будет 100500 дыр которые можно будет тем или иным способом эксплуатировать.

[Дмитрий]

Antonio Solo,


собственно истории когда перли какие нибудь клиентские сертификаты WebMoney - есть

[Antonio Solo]

Дмитрий, токенов для хранения ключей никогда не видел ?

[Дмитрий]

Antonio Solo, видел. И? Еще раз - любая аутентификация предполагает что к вам приползает нечто и говорит что оно Вася Пупкин и в качестве доказательства предлагает что то для проверки. Паспорт, логин-пароль, сертификат, аппаратный ключ с паролем, отпечаток пальца, собственную морду, или анализ крови - в зависимости от договоренности. И вот это все можно спереть. Что то сложно, что то просто.

Answer 1

[Максим]

Недолгоживущий JWT Access Token (5-15мин), который после того как просрочится сделает доступ к сервису невозможным.

Но чтобы каждые 5 минут не простить залогиниться пользователя изобрели RefreshToken, который хранится в базе дольше. Примерно 1 месяц. Он нужен для того, чтобы выпустить новый JWT AccessToken. При взломе RefreshToken просто удаляется и новый AccessToken выпустить не получиться. Почитайте в целом про OAuth 2.0 + JWT

Answer 2

[ThunderCat]

Опять не подходит потому что куки могут украсть.

Откуда вы такие специалисты по безопасности беретесь?..

Вопрос остаётся - как реализовать нормальный и безопасный способ для такой функции, чтобы больше не приходилось использовать другие варианты после каждой очередной жалобы на взлом?

Взлом через уведенную куку входит в топ 5 малореальных сценариев взлома, если у вас есть хоть какая-то защита от XSS.

Хранить IP последнего входа в аккаунт? Идея неплохая, но если каким-то магическим образом БД взломают, то все айпи попадут нехорошим людям.

Оу, вас это больше всего расстраивает? Учитывая что 80% траффика сейчас идет через мобильные сети, айпи будет разниться при каждой сессии авторизации. И в данном случае вероятность такого взлома вы почему-то оцениваете практически как "магию", в то время как доступ к кукам пользователя у вас на уровне "ну, это точно случится, и скорее всего раньше, чем позже, любой может там гулять как у себя дома"...

Comments

[Ипатьев]

Да в общем-то и с XSS не должно быть, если использовать http-only. Сейчас вроде бы все браузеры уже поддерживают

[ThunderCat]

Ипатьев, Ну так да, просто нормально настроенные заголовки сервера уже дают защиту практически на 100%, а тут у нас сильное заявление про "куки это небезопасно!"...

Answer 3

[Александр]

Временный токен средствами JWT