ما مدى حتمية معرّفات .Net GUIDs؟

Question

بالأمس سألت هل المعرفات الفريدة العمومية (GUIDs) التي تم إنشاؤها على نظام التشغيل Windows 2003 آمنة للاستخدام كمعرفات الجلسة؟ والإجابة مجتمعة مع هذه المقالة تعد المعرفات الفريدة العمومية (GUIDs) فريدة عالميًا، لكن السلاسل الفرعية للمعرفات العمومية الفريدة (GUIDs) ليست كذلك دفعني إلى التفكير في استبدال آليتي الحالية لاستخدام المعرفات الفريدة العمومية (GUIDs) كمعرفات الجلسة في ملفات تعريف الارتباط.

نظرًا لأن إجراء هذا التغيير يتطلب القليل من العمل، فقد قررت إجراء اختبار سريع للمعرفات الفريدة العمومية (GUID) على جهاز الكمبيوتر الشخصي الذي يعمل بنظام التشغيل Vista لمعرفة ما إذا كان تسلسل المعرفات الفريدة العمومية (GUIDs) محددًا بشكل واضح (ما يقلقني هو ما إذا كان المهاجم قادرًا على الحصول على تسلسل من المعرفات الفريدة العمومية (GUIDs) التي تم إنشاؤها بواسطة الخادم الخاص بي ستكون قادرة على إنشاء معرفات مطابقة جديدة).

في مقالة ريموند تشين (التي تشير إلى هذه المواصفات القديمة جدًا UUIDs وGUIDs من عام 1998) يتكون GUID من:

• 60 بت من الطابع الزمني،
• 48 بت من معرف الكمبيوتر،
• 14 بت من uniqueifier، و
• تم إصلاح ستة بتات

بالاستمرار في ذلك، إذا قمت بإنشاء 10 معرفات GUID، فإن أول 15 حرف ASCII (باستثناء '-') هي الطابع الزمني، و12 حرف ASCII التالية هي معرف الكمبيوتر، وأحرف ASCII الـ 3.5 التالية عشوائية ويتم إصلاح آخر 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

النمط الوحيد الذي يمكن تمييزه من الفحص البصري السريع هو أن حرف ASCII الثالث عشر هو دائمًا 4.

لقد تركت أتساءل مرة أخرى عما إذا كان الاعتماد على System.Guid لإنشاء معرفات جلسة عشوائية زائفة قويًا بما يكفي لحماية تطبيق ويب حيث قد يكون تكسير معرف الجلسة يستحق آلاف الدولارات على الأكثر؟

تحديث:بدلاً من استخدام المعرف الفريد العمومي (GUID)، أخطط الآن لإنشاء معرف الجلسة الخاص بي باستخدام الطريقة الموضحة أدناه.أقوم بتحويل الرقم العشوائي 384 بت إلى سلسلة بايت 0x00 بحيث يكون مناسبًا للاستخدام في ملف تعريف ارتباط 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

إنها ليست إجابة كاملة، لكن يمكنني أن أخبرك أن الرقم السداسي الثالث عشر هو دائمًا 4 لأنه يشير إلى إصدار الخوارزمية المستخدمة لإنشاء المعرف الفريد العمومي (ID est، v4)؛أيضًا، وأقتبس من ويكيبيديا:

Cryptanalysis of the WinAPI GUID generator shows that, since the sequence of V4 GUIDs is pseudo-random, given the initial state one can predict up to the next 250 000 GUIDs returned by the function UuidCreate. This is why GUIDs should not be used in cryptography, e.g., as random keys.

بقية المقال ومراجعه: http://en.wikipedia.org/wiki/Guid

--يحرر--

من وجهة نظر أمنية، أقترح عليك إنشاء معرف الجلسة الخاص بك بالطريقة التي تريدها، ثم التوقيع عليه بشكل مشفر؛وبهذه الطريقة يمكنك تعبئة أي معلومات تريدها ثم توقيع التوقيع في النهاية - المشكلة المحتملة هي المقايضة بين حجم/قوة مفتاحك والحجم الناتج لملف تعريف الارتباط.تعد المعرفات الفريدة العمومية (GUIDs) مفيدة كمعرفات، ولكنني سأعتمد فقط على تقنية تشفير مخصصة للأمان.

Answer 2

أقترح عليك استخدام System.Security.Cryptography.RandomNumberGenerator.تم تصميم هذا لإنتاج أرقام لا يمكن إجراء هندسة عكسية لها.الدافع وراء Guid هو أن تكون فريدًا.يمكنك الجمع بين كل من المعرف الفريد العمومي (GUID) والرقم العشوائي الآمن، ولكن الرقم العشوائي الآمن 128 بت لن يتعارض أبدًا أثناء التدريب.

Answer 3

بعض الملاحظات:

1. أشك في أن أي تطبيق للمعرفات الفريدة العمومية (GUIDs) قد تم تصميمه ليكون آمنًا من الناحية المشفرة.(وهذا الافتراض تؤكده المقالة المرتبطة بالعنصر التالي.)
2. الحرف ASCII الثالث عشر هو دال على ما هي الخوارزمية التي تم استخدامها لإنشاء GUID.

إذا كنت مهتمًا حقًا بالحصول على معرفات جلسة قوية، فربما تكون التجزئة الآمنة تشفيرًا لشيء لا يمكن تحديده من خارج الجهاز هي أفضل طريقة لك.ربما توليد أ لوحة وقت واحد من بعض المستندات الداخلية أو مصدر البيانات قد ينجح أيضًا.

Answer 4

ماذا تحاول أن تفعل؟هل تريد مجرد مصدر للأرقام العشوائية؟

الدفع عشوائي.org و hotbits.منذ عدة سنوات مضت، كان لدي مكتبة Java يمكنها جمع الأرقام من هذه المصادر وضمها معًا للحصول على سلسلة عشوائية جميلة جدًا (على الرغم من أنها تفترض أن الموقعين ليسا في cahootz).

Answer 5

الإجابة المختصرة هي أنه لا توجد أدلة إرشادية ليست قوية بما يكفي لإنشاء معرف الجلسة إذا كنت تريد منع تخمين معرف الجلسة وتكسيره.

لنفس السبب الذي يجعلك لا ترغب في استخدام المعرف الفريد العمومي (GUID) كمفتاح AES، فأنت لا تريد استخدامه لأي نوع من المعرفات الحساسة.

يعمل المعرّف الفريد العمومي (GUID) بشكل جيد للغاية بالنسبة لما تم تصميمه ليكون:معرف فريد مضمون رياضيًا لن يتكرر أبدًا.

حتى لو كان كسر معرف الجلسة يساوي 1000 دولار فقط، تخيل لو تم ذلك 100 مرة.الآن أنت تتحدث بجدية.

أعلم أنها طريقة سهلة لاستخدام المعرفات الفريدة العمومية (GUID) ولكن قاومها وتعامل معها من خلال اتخاذ الاحتياطات المناسبة لتأمين تطبيقك بشكل مناسب.سوف يشكرك المستخدمون.

Answer 6

يكاد يكون من المستحيل الحصول على دليل مكرر مع الأخذ في الاعتبار إمكانية الحصول عليه.فيما يلي بعض الحقائق الرياضية السريعة

حبات الرمل في العالم 75,000,000,000,000,000,000

عدد المعرفات الفريدة العمومية (GUIDs) 340,282,366,920,938,463,463,374,607,431,770,000,000