NewID() - есть ли высокая вероятность раскрытия предыдущего / следующего GUID

Я знаю, что идентификаторы GUID теоретически уникальны с очень низкой вероятностью столкновения. Тем не менее, если я правильно понимаю, некоторая уникальность доступна, потому что она основана на информации на компьютере, который использовался для ее генерации, в зависимости от используемого алгоритма.

Насколько вероятно, что при наличии GUID пользователь может угадать другие GUID в таблице?

Например, если у вас есть подписчики на новостную рассылку с функцией отписки, вы можете просто разместить ее на example.com/subscriber/unsubscribe/ndomid}

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

Если в столбце идентификаторов указан идентификатор GUID, инициализированный функцией newid(), насколько вероятно, что ваш пользователь сможет угадать правильные идентификаторы, если они знают их?

Источник

2 ответа

Решение

I'd say that it's probably possible in theory, but very, very unlikely to actually happen.

I've read Eric Lippert's blog posts that SLaks linked in his comment, and some other answers on Stack Overflow:

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

Теперь я предполагаю, что, учитывая только один GUID (идентификатор подписки на рассылку из примера), будет очень трудно угадать любой другой GUID.
Если (и только если) это действительно возможно, вам, вероятно, нужна быстрая машина и глубокие знания об алгоритмах, используемых для создания GUID.

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

Источник

NEWID() генерирует GUID версии 4, но его реализация является предположительной. GUID разработаны так, чтобы быть уникальными, а не случайными.

Из спецификации RFC 4122:

Вопросы безопасности

Не думайте, что UUID трудно угадать; они не должны использоваться в качестве средств обеспечения безопасности (идентификаторов, чье простое владение
доступ), например. Предсказуемый источник случайных чисел
усугубить ситуацию.

Как указал @martin-smith только потому, что GUID жалобы версии 4 не делает его по сути догадывающимся, это зависит от реализации. В этом посте об обмене стеками показано, как создать GUID версии 4 жалобы с использованием SQL, что невозможно угадать:

SELECT CAST(CRYPT_GEN_RANDOM(16) AS UNIQUEIDENTIFIER)

Рекомендации:

Источник
Другие вопросы по тегам