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

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

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

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

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

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


person programmerdave    schedule 12.05.2014    source источник


Ответы (1)


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

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

person Zólyomi István    schedule 14.05.2014