Как детерминированные являются .Net GUID?

Question

Вчера я спросил Are GUIDs generated on Windows 2003 safe to use as session IDs?, и ответ в сочетании с этой статьей GUIDs are globally unique, but substrings of GUIDs aren't побудил меня задуматься о замене моего текущего механизма использования GUID в качестве идентификаторов сеанса в файлах cookie.

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

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

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

Идущий тем, что, если я произвожу 10 GUIDs й Первые 15 символов ASCII (исключая «-») являются меткой времени, следующие 12 символов ASCII являются идентификатором компьютера, следующие 3.5 символа ASCII являются случайными, а последние 1,5 символа фиксированы.

Получение 10 GUIDs на моем 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, чтобы он был подходящим для использования в HTTP-файле cookie.

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 (EST ID, v4); Кроме того, цитирую Википедия:

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

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

--Edit--

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

Answer 2

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

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

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

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

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

Answer 3

Некоторые примечания:

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

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

Answer 4

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

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

Answer 5

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

песчинок в мире 75.000.000.000.000.000.000

Количество GUIDs 340,282,366,920,938,463,463,374,607,431,770,000,000

Answer 6

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