Насколько детерминированы .Net GUID?

Question

Вчера я спросил Безопасно ли использовать идентификаторы GUID в Windows 2003 для использования в качестве идентификаторов сеансов? и ответ в сочетании с этой статьей Глобальные идентификаторы GUID уникальны, но подстроки идентификаторов GUID не являются побудил меня подумать о замене моего текущего механизма использования идентификаторов GUID в качестве идентификаторов сеансов в файлах cookie.

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

В статье Рэймонда Чена (которая ссылается на эту очень старую спецификацию UUID и GUID). с 1998 г.) GUID состоит из:

• 60 бит отметки времени,
• 48 бит идентификатора компьютера,
• 14 битов Uniquifier и
• фиксированные шесть битов

Исходя из того, что если я сгенерирую 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);

Answer 1

Это не полный ответ, но я могу вам сказать, что 13-я шестнадцатеричная цифра всегда равна 4, потому что она обозначает версию алгоритма, используемого для генерации GUID (id, v4); также, и я цитирую Википедию:

Криптоанализ WinAPI GUID генератор показывает, что, так как последовательность идентификаторов GUID V4 является псевдослучайной, учитывая начальное состояние можно прогнозировать до следующих 250 000 GUID возвращается функцией UuidCreate. Вот почему не следует использовать GUID в криптографии, например, в качестве случайных ключей.

Остальная часть статьи и ссылки на нее: http://en.wikipedia.org/wiki/Guid

- Edit -

С точки зрения безопасности, я бы посоветовал вам сгенерировать свой идентификатор сессии, как вам хочется, а затем криптографически подписать его; таким образом, вы можете упаковать любую информацию, какую захотите, а затем просто поставить подпись на конце - возможной проблемой является компромисс между размером / силой вашего ключа и результирующим размером файла cookie. Идентификаторы GUID полезны в качестве идентификаторов, но для обеспечения безопасности я бы полагался только на специальный криптографический метод.

Answer 2

Я предлагаю вам использовать System.Security.Cryptography.RandomNumberGenerator . Это разработано, чтобы произвести числа, которые не могут быть перепроектированы. Мотивация Guid - быть уникальным. Вы можете комбинировать как GUID, так и безопасное случайное число, но 128-битное безопасное случайное число никогда не столкнется на практике.

Answer 3

Некоторые заметки:

1. Я сомневаюсь, что любая реализация GUID была разработана для криптографической защиты. (И это предположение подтверждается статьей, на которую ссылается следующий пункт.)
2. 13-й символ ASCII является символом , какой алгоритм использовался для генерации GUID .

Если вы действительно обеспокоены наличием надежных идентификаторов сеансов, то, возможно, ваш криптографически безопасный хэш чего-то, что не может быть определено вне машины, будет вашим лучшим подходом. Возможно, будет сгенерирован одноразовый блокнот из какого-либо внутреннего документа или источника данных.

Answer 4

Практически невозможно получить дубликат руководства, учитывая возможности его получения. Вот несколько быстрых математических фактов

Песчинки в мире 75 000 000 000 000 000 000

Количество идентификаторов GUID 340 282 366 920 938 463 463 374 607 431 770 000 000

Answer 5

Что вы пытаетесь сделать? Вы хотите просто источник случайных чисел?

Проверьте random.org и hotbits . Много-много лет назад у меня была библиотека Java, которая собирала числа из этих источников и соединяла их вместе, чтобы получить довольно красивый случайный ряд (хотя предполагается, что два сайта не в cahootz).

Answer 6

Краткий ответ: ни один guid не является достаточно сильным, чтобы генерировать идентификаторы сеанса, если вы хотите предотвратить угадывание и взлом идентификатора сеанса.

По той же причине, по которой вы не хотите использовать GUID в качестве ключа AES, вы не хотите использовать их для любых типов конфиденциальных идентификаторов.

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

Даже если взлом идентификатора сеанса стоит всего 1000 долларов, представьте, если это будет сделано 100 раз. Теперь ты говоришь о серьезных побрякушках.

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