Как детерминированные являются .Net GUID?
Вчера я спросил Являются ли GUID, сгенерированные в Windows 2003 безопасными для использования в качестве идентификаторов сеансов?, и ответ в сочетании с этой статьей GUID глобально уникальны, но подстроки GUID не меняют, поэтому я подумал о замене моего текущего механизма использования GUID как идентификатора сеанса в файлах cookie.
Поскольку для этого было немного работы, я решил запустить быстрый тест GUID на своем ПК с Vista, чтобы узнать, была ли последовательность идентификаторов GUID явно детерминированной (что меня беспокоит, если злоумышленник смог получить последовательность GUID, сгенерированных моим сервером, они могли бы генерировать новые сопоставимые).
В статье Раймонда Чена (которая ссылается на эту очень старую спецификацию UUID и GUID от 1998 года), GUID состоит из:
- 60 бит метки времени,
- 48 бит идентификатора компьютера,
- 14 бит уникального идентификатора и
- фиксируются шесть бит
Исходя из этого, если я генерирую 10 GUID, первые 15 символов ASCII (исключая "-" ) являются меткой времени, следующие 12 символов ASCII являются идентификатором компьютера, следующие 3,5 символа ASCII являются случайными, а последние 1,5 символа фиксированы.
Получение 10 GUID на моем ПК с Vista с помощью .Net System.Guid.NewGuid() дает:
b4e95ead-3619-4dc2-9102-cf7ab0efd927
a45ee719-decd-46b2-8355-7becbe406f74
9af68d75-35a0-4907-b6ab-f15e33acfe96
bed88fa3-3209-4a19-97dd-85d5428ea5f4
123cb39b-8d81-41c6-8894-f1257a8f7606
e2b1f6b1-5791-4a18-80a9-5dc668574ecb
c52aa660-2629-4659-bb83-5583081e5a1c
76eda32d-ceda-412e-8ade-30c47416e954
cbc4d45e-7281-40d2-9f90-00539b04fe98
be36524c-267c-4791-bc9e-3c20b29d7615
Единственный заметный паттерн из быстрого визуального контроля - это то, что 13-й символ ASCII всегда равен 4.
Мне снова не интересно, полагается ли полагаться на System.Guid для генерации псевдослучайных идентификаторов сеансов, чтобы защитить веб-приложение, где взлом идентификатора сеанса будет стоить не более тысячи долларов?
Обновление. Вместо использования GUID теперь я планирую сгенерировать свой идентификатор сеанса, используя подход ниже. Я преобразовываю 384-битное случайное число в строку с байтом 0x00, чтобы оно было подходящим для использования в файле cookie HTTP.
RNGCryptoServiceProvider rngProvider = new RNGCryptoServiceProvider();
byte[] myKey = new byte[48];
rngProvider.GetBytes(myKey);
string sessionID = null;
myKey.ToList().ForEach(b => sessionID += b.ToString("x2"));
Console.WriteLine(sessionID);
Ответы
Ответ 1
Это не полный ответ, но могу сказать, что 13-я шестнадцатеричная цифра всегда 4, потому что она обозначает версию алгоритма, используемого для генерации GUID (id est, v4); также, и я цитирую Wikipedia:
Криптоанализ GUID WinAPI генератор показывает, что, поскольку последовательность идентификаторов GUID V4 является псевдослучайной, учитывая начальное состояние, можно прогнозировать до 250 000 GUID возвращенный функцией UuidCreate. Вот почему GUID не должны использоваться в криптографии, например, в виде случайных ключей.
Остальная часть статьи и ее ссылки: http://en.wikipedia.org/wiki/Guid
- Edit -
С точки зрения безопасности, я предлагаю вам сгенерировать идентификатор сеанса, но, как вам кажется, затем криптографически подписать его; таким образом, вы можете упаковать любую нужную информацию, а затем просто пощекотать подпись в конце - возможная проблема - это компромисс между размером/силой вашего ключа и результирующим размером файла cookie. GUID полезны в качестве идентификаторов, но я полагаюсь только на специальный криптографический метод безопасности.
Ответ 2
Я предлагаю вам использовать System.Security.Cryptography.RandomNumberGenerator. Это предназначено для создания чисел, которые невозможно преобразовать назад. Гид мотивации должен быть уникальным. Вы могли бы объединить как GUID, так и безопасное случайное число, но 128-битное безопасное случайное число никогда не будет иметь столкновений на практике.
Ответ 3
Некоторые примечания:
- Я сомневаюсь, что любая реализация GUID была разработана как криптографически безопасная. (И это предположение будет подтверждено статьей, связанной для следующего пункта.)
- 13-й символ ASCII является означающим какой алгоритм использовался для генерации GUID.
Если вы действительно заинтересованы в наличии сильных идентификаторов сеанса, возможно, криптографически безопасный хэш чего-то, что невозможно определить из-за машины, будет вашим лучшим подходом. Возможно, даже работала бы одноразовая панель из какого-то внутреннего документа или источника данных.
Ответ 4
Что вы пытаетесь сделать? Вы хотите просто источник случайных чисел?
Отметьте random.org и hotbits. Много лет назад у меня была библиотека Java, которая собирала числа из этих источников и объединяла их вместе, чтобы получить довольно красивый случайный ряд (хотя он предполагает, что два сайта не находятся в cahootz).
Ответ 5
Короткий ответ: ни один указатель не достаточно силен для генерации идентификатора сеанса, если вы хотите избежать угадывания и взлома идентификатора сеанса.
По той же причине, почему вы не хотели бы использовать GUID в качестве ключа AES, вы не хотите использовать их для любого типа чувствительных идентификаторов.
GUID работает очень хорошо для того, для чего они предназначены: математически гарантированный уникальный идентификатор никогда не повторяется.
Даже если взломать идентификатор сеанса стоит всего 1000 долларов, представьте, если это делается 100 раз. Теперь вы говорите о серьезном блеске.
Я знаю, что это простой способ использовать GUID, но сопротивляться и бороться с болью, принимая надлежащие меры предосторожности для надлежащей защиты вашего приложения. Ваши пользователи будут благодарны вам.
Ответ 6
Почти невозможно получить дубликат guid, учитывающий возможности его получения. Вот некоторые быстрые математические факты.
Зерна песка в мире 75 000 000 000 000 000 000
Число идентификаторов GUID 340,282,366,920,938,463,463,374,607,431,770,000,000