Насколько безопасно использовать UUID для однозначной идентификации чего-либо (я использую его для файлов, загружаемых на сервер)? Насколько я понимаю, это основано на случайных числах. Тем не менее, мне кажется, что если бы у меня было достаточно времени, это, в конце концов, повторилось бы самостоятельно, просто по чистой случайности. Есть ли лучшая система или шаблон какого-то типа, чтобы облегчить эту проблему?
guid
uniqueidentifier
uuid
Джейсон
источник
источник
Ответы:
Очень безопасно:
Предостережение:
Источник: раздел Случайная вероятность UUID дубликатов в статье Википедии об универсально уникальных идентификаторах (ссылка ведет к пересмотру с декабря 2016 года, прежде чем редактирование переработало раздел).
Также см. Текущий раздел на ту же тему в той же статье с универсальным уникальным идентификатором, Collisions .
источник
Если под «достаточным количеством времени» вы подразумеваете 100 лет и создаете их со скоростью миллиард в секунду, то да, у вас есть 50% шанс столкновения через 100 лет.
источник
Существует более одного типа UUID, поэтому «насколько безопасно» зависит от того, какой тип (который спецификации UUID называют «версия») вы используете.
Версия 1 основана на времени плюс UUID MAC-адреса. 128-бит содержит 48 бит для MAC-адреса сетевой карты (который уникально назначен производителем) и 60-битную тактовую частоту с разрешением 100 наносекунд. Эти часы помещаются в 3603 AD, поэтому эти UUID безопасны по крайней мере до тех пор (если вам не нужно более 10 миллионов новых UUID в секунду или кто-то клонирует вашу сетевую карту). Я говорю «по крайней мере», потому что часы начинаются 15 октября 1582 года, поэтому у вас есть около 400 лет после того, как часы завернутся, прежде чем появится даже небольшая вероятность дублирования.
Версия 4 - это случайное число UUID. Там шесть фиксированных битов, а остальная часть UUID составляет 122 бита случайности. Посмотрите Википедию или другой анализ, который описывает, насколько маловероятным является дубликат.
Версия 3 использует MD5, а версия 5 использует SHA-1 для создания этих 122 битов вместо генератора случайных или псевдослучайных чисел. Так что с точки зрения безопасности это похоже на статистическую проблему версии 4 (при условии, что алгоритм обработки дайджеста всегда уникален).
Версия 2 похожа на версию 1, но с меньшими часами, поэтому она будет гораздо раньше. Но поскольку UUID версии 2 предназначены для DCE, их не следует использовать.
Так что для всех практических задач они безопасны. Если вам неудобно оставлять это до вероятности (например, вы относитесь к тому типу людей, которых беспокоит разрушение Земли большим астероидом в течение вашей жизни), просто убедитесь, что вы используете UUID версии 1, и он гарантированно будет уникальным ( в вашей жизни, если вы не планируете жить после 3603 г. н.э.).
Так почему же не все просто используют UUID версии 1? Это связано с тем, что идентификаторы UUID версии 1 показывают MAC-адрес компьютера, на котором он был создан, и они могут быть предсказуемы - две вещи, которые могут иметь последствия для безопасности приложения, использующего эти идентификаторы UUID.
источник
Ответ на это может зависеть в значительной степени от версии UUID.
Многие генераторы UUID используют случайное число версии 4. Однако многие из них используют генератор псевдослучайных чисел для их генерации.
Если для генерации UUID используется плохо посеянный PRNG с небольшим периодом, я бы сказал, что это совсем не безопасно.
Следовательно, он настолько же безопасен, насколько и алгоритмы, используемые для его генерации.
С другой стороны, если вы знаете ответ на эти вопросы, то я думаю, что uuid версии 4 должен быть очень безопасным в использовании. На самом деле я использую его для идентификации блоков в файловой системе сетевых блоков и до сих пор не сталкивался.
В моем случае PRNG, который я использую, является мерсенновым твистером, и я осторожен с тем, как он просеивается из нескольких источников, включая / dev / urandom. Твистер Мерсенна имеет период 2 ^ 19937 - 1. Пройдет очень и очень много времени, прежде чем я увижу повторяющуюся волну.
источник
Цитата из Википедии :
Далее достаточно подробно объясняется, насколько это безопасно на самом деле. Итак, чтобы ответить на ваш вопрос: да, это достаточно безопасно.
источник
Я согласен с другими ответами. UUID достаточно безопасны практически для всех практических целей 1 и, конечно, для ваших.
Но предположим (гипотетически), что это не так.
Вот несколько подходов:
Используйте больший UUID. Например, вместо 128 случайных битов, используйте 256 или 512 или ... Каждый бит, который вы добавляете к UUID типа 4, уменьшит вероятность коллизии вдвое, предполагая, что у вас есть надежный источник энтропии 2. ,
Создайте централизованную или распределенную службу, которая генерирует идентификаторы UUID и регистрирует каждую из них, которую она когда-либо выпускала. Каждый раз, когда он генерирует новый, он проверяет, что UUID никогда не выдавался раньше. Такой сервис был бы технически прост в реализации (я думаю), если бы мы предполагали, что люди, работающие с сервисом, были абсолютно заслуживающими доверия, неподкупными и так далее. К сожалению, они не ... особенно, когда есть возможность вмешательства правительственных служб безопасности. Таким образом, этот подход, вероятно , нецелесообразно, и может быть 3 невозможно в реальном мире.
1. Если бы уникальность UUID определяла, были ли запущены ядерные ракеты в столице вашей страны, многие из ваших сограждан не были бы убеждены в том, что «вероятность крайне мала». Отсюда и моя «почти вся» квалификация.
2 - И вот вам философский вопрос. Что-нибудь действительно случайное? Как мы узнаем, что это не так? Является ли вселенная, какой мы ее знаем, симуляцией? Есть ли Бог, который мог бы «настроить» законы физики, чтобы изменить результат?
3 - Если кто-нибудь знает какие-либо исследовательские работы по этой проблеме, пожалуйста, прокомментируйте.
источник
Схемы UUID, как правило, используют не только псевдослучайный элемент, но также текущее системное время и некоторый вид часто уникального идентификатора оборудования, если таковой имеется, например, сетевой MAC-адрес.
Весь смысл использования UUID состоит в том, что вы доверяете ему сделать лучшую работу по предоставлению уникального идентификатора, чем вы сами могли бы сделать. Это то же самое обоснование использования сторонней библиотеки криптографии, а не использования собственной. Делать это самостоятельно может быть веселее, но обычно это менее ответственно.
источник
Делал это годами. Никогда не сталкивайтесь с проблемой.
Я обычно настраиваю свои БД, чтобы иметь одну таблицу, которая содержит все ключи и даты изменения и тому подобное. Никогда не сталкивался с проблемой дубликатов ключей.
Единственный недостаток - когда вы пишете несколько запросов для быстрого поиска информации, вы много копируете и вставляете ключи. У вас нет коротких, легко запоминающихся идентификаторов.
источник
Вот тестовый фрагмент для вас, чтобы проверить его уникальность. вдохновлен комментарием @ scalabl3
Если вам повезло, установите флажок, он проверяет только сгенерированные идентификаторы. Если вы хотите проверить историю, не проверяйте ее. Обратите внимание, что в какой-то момент у вас может кончиться баран, если вы оставите его без контроля. Я попытался сделать его дружественным к процессору, чтобы вы могли быстро прервать его при необходимости, просто нажмите кнопку «Выполнить фрагмент» еще раз или покиньте страницу.
источник
Я не знаю, имеет ли это для вас значение, но имейте в виду, что GUID являются глобально уникальными, а подстроки GUID - нет .
источник
Для UUID4 я установил, что в кубическом коробе со стороной 360 000 км в длину примерно столько же идентификаторов, сколько песчинок. Это коробка со сторонами примерно в 2 1/2 раза длиннее диаметра Юпитера.
Работая так, чтобы кто-то мог сказать мне, если я испортил единицы:
источник