Пытаюсь на php реализовать функцию запоминания пароля. Допустим, при логине сервер генерирует токен и через куки отправляет браузеру. Теперь при последующем посещений сравниваю токен из куки и из базы данных.
Есть небольшой шанс, что сайт распознает какого-то злоумышленника как другого пользователя, ведь злоумышленник может сколько угодно раз менять токен из куки.
Какая длина идентификатора в куках? из каких символов он может состоять?
Умножаете одно на другое и посчитайте кол-во возможных вариантов.
Хотелось бы для начала увидеть эти цифры.
Подсказка: Ид - обычно чисто числовое значение в рамках размерности int, по этому либо вы неверно выразились, либо неверно выбрали направление. Тут нужен большой длинный х**. )))
nokimaro, допустим длина токена 24, цифры и буквы. Злоумышленник может хоть миллион раз менять у себя этот токен и в конце концов взломает какого то пользователя
А чтоб злоумышленник не мог перебирать, вешается rateLimiter на количество запросов с одного ip
И тогда попасть перебором в токен случайного пользователя можно будет лет так за миллиард.
FanatPHP Это верно, но автор не указал, каким образом генерирует токен. Предположу что с помощью random_bytes, он хоть и pseudo-random, но cryptographically secure согласно документации
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 млн лет)
Требуемый параметр называется "криптографической стойкостью".
Большая часть самопальных решений "из букв и цифр" такой стойкостью не обладает.
Как не обладает ей и uuid v4.
На данный момент рекомендуемым решением является использование функции random_bytes() $token = bin2hex(random_bytes(24));
Далее токен пишется в БД и в куки пользователю.
ну значит нужно отдавать не id а uuid v4 (это пример, можно любой другой рандом, чем больше, тем лучше), а id хранить в таблице на стороне сервера, причем можно еще делать отдельную привязку к ip / useragent или времени последнего запроса (например ip (или диапазон) может измениться в течении суток-двух, у useragent версия увеличиться на 1, иначе сессия с таким id невалидна)
FanatPHP, пользуюсь готовыми механизмами фреймворков как правило. А по поводу недостаточной криптостойкости рандомного uuid - в реальных условиях оно достаточно, сугубо ИМХО, конечно.
