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

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

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

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

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

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


sql-server guid newid
person jfrobishow    schedule 17.05.2012    source источник
comment
Ваши опасения очень важны. См. blogs.msdn.com/b/ericlippert/archive/tags/guids < / а>   -  person SLaks    schedule 17.05.2012

Ответы (2)


arrow_upward
3
arrow_downward

Я бы сказал, что теоретически это возможно, но очень, очень маловероятно.

Я читал сообщения в блоге Эрика Липперта, на которые SLaks указал в своем комментарии, и некоторые другие ответы на Stack Overflow:

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

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

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

person Christian Specht    schedule 17.05.2012

arrow_upward
2
arrow_downward

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

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

Соображения безопасности

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

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

SELECT CAST(CRYPT_GEN_RANDOM(16) AS UNIQUEIDENTIFIER)

Ссылки:

person DalSoft    schedule 24.10.2016
comment
Существует разница между не предполагать, что они не могут быть угаданы во всех реализациях, и все реализации, которые создают направляющие версии 4, являются предполагаемыми. - person Martin Smith; 24.10.2016
comment
Хороший момент NEWID () можно угадать и не следует использовать IMO. Но вы можете создать GUID жалобы версии 4, который невозможно угадать. Я изменил свой ответ, чтобы быть более ясным. - person DalSoft; 24.10.2016