Должен ли я хранить все сгенерированные UUIDv4 токены носителя oAuth2 в моей базе данных, чтобы предотвратить атаку?

Question

Я генерирую oauth2-доступ, обновляю токены и сохраняю их в своей базе данных. Я генерирую эти токены, используя UUID v4, и удаляю тире. Раньше я удалял токены после истечения срока их действия, но теперь я храню их все, потому что я думал о том, что может произойти.

Что если злоумышленник хранит локально все токены доступа, которые были сгенерированы для него, и он снова и снова использует эти токены доступа для авторизации. Поскольку я, как администратор БД, удалял сгенерированные токены, БД не может знать, что токен уникален. Поэтому, если алгоритм UUIDv4 генерирует токен доступа для другого пользователя, и это коллизия (тот же UUID, что и ранее созданный), и злоумышленник обнаружил, что коллизия была, он может попасть в службу, поскольку у него есть токены, которые были сгенерированы ранее.

Мой вопрос заключается в том, должен ли я беспокоиться об этом и оставить все свои токены на случай коллизий, чтобы проверить их уникальность, или я должен удалить токены доступа и обновления после их истечения и полагать, что UUIDv4 обладает достаточной энтропией, чтобы предотвратить это?

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

Любая помощь приветствуется!

Answer 1

Хотя в теории существует минимальная вероятность коллизий UUID, весь смысл UUID в том, чтобы быть уникальным на практике, просто рассмотрите название "Универсально уникальный идентификатор". Для расчета вероятности столкновения, см., Например, эту ссылку, я бы не стал сидеть и ждать, пока это произойдет.;-)

Я не ожидаю, что вы сгенерируете достаточно UUID для реалистичного шанса даже одного столкновения. Если вы все еще делаете это, сохранение большого количества маркеров доступа в базе данных также может быть проблемой, возможно, потребуется большое хранилище. Если вы все еще боитесь коллизий, я предлагаю генерировать что-то еще более уникальное, чем UUID, но не храните их все в вашей базе данных.