Насколько безопасна реализация запоминания пользователя?

Question

[Theory Theory]

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

Comments

[FanatPHP]

В каком смысле "небольшой"?

[nokimaro]

Какая длина идентификатора в куках? из каких символов он может состоять?
Умножаете одно на другое и посчитайте кол-во возможных вариантов.
Хотелось бы для начала увидеть эти цифры.

[ThunderCat]

Подсказка: Ид - обычно чисто числовое значение в рамках размерности int, по этому либо вы неверно выразились, либо неверно выбрали направление. Тут нужен большой длинный х**. )))

[Theory Theory]

nokimaro, допустим длина токена 24, цифры и буквы. Злоумышленник может хоть миллион раз менять у себя этот токен и в конце концов взломает какого то пользователя

[Immortal_pony]

Theory Theory Даже 24 символа - это ЗНАЧИТЕЛЬНО больше миллиона. В миллионы раз, такскз-ть.

[Immortal_pony]

А чтоб злоумышленник не мог перебирать, вешается rateLimiter на количество запросов с одного ip
И тогда попасть перебором в токен случайного пользователя можно будет лет так за миллиард.

[FanatPHP]

Immortal_pony, только один ньюанс. Для криптографически нестойкого значения не обязательно подбирать все варианты.

[Immortal_pony]

FanatPHP Это верно, но автор не указал, каким образом генерирует токен. Предположу что с помощью random_bytes, он хоть и pseudo-random, но cryptographically secure согласно документации

[FanatPHP]

Immortal_pony, не вижу ни одной причины предполагать random bytes.
скорее rand по массиву с алфавитом в цикле

[Immortal_pony]

FanatPHP тостер испортил тебя, ты теряешь веру в людей ))
Theory Theory, но если FanatPHP всё же прав, то генерируй токен на основании random_bytes.
Вот, можешь у Yii реализацию подсмотреть, например: https://github.com/yiisoft/security/blob/master/sr...

[nokimaro]

Theory Theory, a-zA-Z0-9 = 62 доступных символа
длина токена 24 символа
количество возможных комбинаций
96,977,332,473,382,725

чтобы проверить работу токена злоумышленнику надо отправлять HTTP запрос на сайт
предположим он отправляет 100 запросов В СЕКУНДУ

96,977,332,473,382,725 / 100 = 969 773 324 733 827 секунд нужно делать 100 запросов в секудну на гарантированный подбор одного токена
969 773 324 733 827 секунд = 30 751 310 лет (30 млн лет)

Answer 1

[FanatPHP]

Требуемый параметр называется "криптографической стойкостью".
Большая часть самопальных решений "из букв и цифр" такой стойкостью не обладает.
Как не обладает ей и uuid v4.

На данный момент рекомендуемым решением является использование функции random_bytes()
$token = bin2hex(random_bytes(24));
Далее токен пишется в БД и в куки пользователю.

Answer 2

[Антон Антон]

ну значит нужно отдавать не id а uuid v4 (это пример, можно любой другой рандом, чем больше, тем лучше), а id хранить в таблице на стороне сервера, причем можно еще делать отдельную привязку к ip / useragent или времени последнего запроса (например ip (или диапазон) может измениться в течении суток-двух, у useragent версия увеличиться на 1, иначе сессия с таким id невалидна)

Comments

[FanatPHP]

Скажите, вы лично делали когда-нибудь такую "привязку"?

[Антон Антон]

FanatPHP, пользуюсь готовыми механизмами фреймворков как правило. А по поводу недостаточной криптостойкости рандомного uuid - в реальных условиях оно достаточно, сугубо ИМХО, конечно.