Я намерен использовать UNIQUEIDENTIFIERв качестве ключа доступа, который пользователи могут использовать для доступа к определенным данным. Ключ будет действовать как пароль в этом смысле.
Мне нужно сгенерировать несколько таких идентификаторов как часть INSERT...SELECTзаявления. По архитектурным соображениям я хочу генерировать идентификаторы на стороне сервера в этом случае.
Как я могу создать надежно случайный UNIQUEIDENTIFIER? Обратите внимание, что NEWIDэто не было бы достаточно случайным, поскольку это не обещает никаких свойств безопасности вообще. Я ищу SQL Server эквивалент System.Security.Cryptography.RandomNumberGenerator, потому что мне нужны неосуществимые идентификаторы. Все, что основано CHECKSUM, RANDили не GETUTCDATEбудет соответствовать требованиям.
4. Но тот факт, что у меня нет убедительных доказательств того, что они могут быть угаданными, не означает, что это не так. Я не могу основать это решение по безопасности на этом наблюдении.Ответы:
Должен сделать трюк, я бы подумал.
CRYPT_GEN_RANDOMисточник
Просто мои два цента, но это может быть не очень хорошая идея. Перефразируя превосходную серию Эрика Липперта о GUID ( часть 1 , часть 2 , часть 3 ), аббревиатура - GUID, а не GSUID - глобальный уникальный идентификатор, а не глобальный безопасный уникальный идентификатор.
Проблема заключается в том, что когда GUID генерируются в не враждебной области, такой как каждый, использующий NEWID (), гарантируется, что все значения будут уникальными (ну, вроде как, см. Статью Эрика, часть 3). Но если вражеский объект входит в эту область, они могут как предсказать следующий сгенерированный GUID, так и вызвать конфликты самостоятельно.
Создав свой собственный метод генерации значения, которое вы храните внутри структуры, которая выглядит как GUID, вы по существу стали враждебной сущностью. Вы изменили контракт GUID с уникального на случайный . Хотя кто-то лучше, чем я, мог бы доказать, что вы все еще уникальны, это только в рамках метода вашего поколения. Если вы смешаете эти псевдо-GUID с NEWID (), все ставки будут отключены.
Я говорю, что это не может быть хорошей идеей только потому, что я не знаю всего, как вы используете значения. Если вы являетесь единственным объектом, генерирующим значения (без смешивания и сопоставления), и / или вы не сохраняете значения, и / или вас не волнуют коллизии, это может не быть проблемой. Если какой-либо из этих пунктов не соответствует действительности, вы можете переоценить.
источник
UNIQUEIDENTIFIERв основном совпадение. С этим типом просто удобно обрабатывать 16-байтовое количество. Я думаю об этом как пароль. Это должно быть уникальным, хотя. Я уверен, что никогда не увижу столкновения (и даже если приложение будет просто зависать - это тоже безопасно).Согласно https://blogs.msdn.microsoft.com/sqlprogrammability/2006/03/23/newsequentialid-histrorybenefits-and-implementation/ , функция NEWID () просто оборачивает функцию Windows CoCreateGuid, которая возвращает GUID в стиле v4 , И согласно https://msdn.microsoft.com/en-us/library/bb417a2c-7a58-404f-84dd-6b494ecf0d13#id11 , начиная с Windows 2000 еще в 1999 году,
Поэтому я бы сказал, что вы можете считать NEWID () криптографически безопасным - по крайней мере, в той степени, в которой он обеспечивает 122 бита энтропии.
источник