أدوات المطور · مولد UUID
Math.random مقابل crypto.getRandomValues: كيف يعمل كل مولد
· كيف يعمل
uuid التشفير متصفح API
كلاهما يعرضان أرقامًا تبدو عشوائية، لكن أحدهما عبارة عن آلة حالة حتمية صغيرة والآخر يتم تغذيته بواسطة نظام التشغيل. إليك ما يفعله كل منهما أسفل الغطاء ولماذا يجب على UUIDs استخدام الثاني.
مقتطف المنتدى الذي ينشئ UUID من Math.random - لماذا يبدو جيدًا ويجتاز كل اختبار غير رسمي
تقدم إجابة المنتدى مصنعًا سريعًا UUID في ثمانية أسطر: قم بتجميع القيم من Math.random وقم بتنسيقها في التخطيط 8-4-4-4-12. يبدو الرمز جيدًا ويجتاز كل اختبار غير رسمي. يظهر كل معرف مختلفًا، ولا تظهر العينة القصيرة أي نمط مرئي واضح. هذه ليست الخاصية التي يحتاجها المعرف الحساس للأمان. يحدد JavaScript Math.random كمصدر عشوائي زائف ولكنه لا يتطلب مقاومة تشفير للتنبؤ. وتشمل وظائفها المناسبة المحاكاة والألعاب والخلط. بمجرد أن يتمكن المعرف من التأثير على الوصول أو اكتشاف الأشياء أو أي قرار عدائي آخر، فإن المظهر لم يعد دليلاً. يعد عقد المولد الموثق أكثر أهمية من مجرد صفحة ذات مظهر معقول.
داخل Math.random — خوارزمية عشوائية زائفة ذات حالة داخلية ثابتة، مصممة للسرعة والانتشار الإحصائي، وليس السرية
نظرًا لأن Math.random لم يتم تحديده كمولد تشفير، فلا يجب التعامل مع مخرجاته كدليل على إخفاء القيم المستقبلية عن المراقب. crypto.getRandomValues لديه عقد منصة مختلف: فهو يملأ مصفوفة مكتوبة بأعداد صحيحة بقيم قوية من الناحية التشفيرية. تترك مواصفات Web Crypto المولد الدقيق لوكيل المستخدم، لذلك يجب ألا يطالب كود التطبيق بخوارزمية معينة أو حجم بذرة أو جهاز إنتروبيا معين. يحتاج ToolAcre إلى الحد المدعوم فقط: يوفر المتصفح وحدات بايت عشوائية آمنة، ويتلقى JavaScript Uint8Array المعبأ، ويقوم رمز UUID بتعيين الإصدار وحقول المتغيرات. يعد هذا البيان مفيدًا ومحمولًا عبر المتصفحات التي تختلف تطبيقاتها الداخلية.
لماذا يمكن أن تكشف مراقبة المخرجات عن الحالة - كيف يمكن لحالة صغيرة أن تعني أن سلسلة من القيم يمكن أن تسمح لشخص ما بالتنبؤ بالحالات التالية
يتلقى رمز التطبيق قيمًا قوية تشفيرًا من getRandomValues بدلاً من تنفيذ أو كشف حالة JavaScript PRNG. يظهر الفرق الأمني في الأنظمة الحقيقية. المعرف الذي تم إنشاؤه من Math.random غير مناسب حيثما يكون للتنبؤ عواقب لأن المهاجم الذي لديه القدرة على قراءة الشبكة (أو أي نظام تكون فيه UUIDs السابقة مرئية) يمكنه التنبؤ بالمعرف التالي. الإصدار 4 UUID من crypto.getRandomValues ليس في حد ذاته رمزًا مميزًا للمصادقة (لا تزال بحاجة إلى انتهاء الصلاحية، والتجزئة، وتحديد المعدل)، ولكن المولد مصمم لمقاومة التنبؤ. ToolAcre يرفض إنشاء معرف إذا كان مصدره الآمن غائبًا، بدلاً من الرجوع بصمت إلى صيغة يمكن التنبؤ بها. تم شحن Math.random مع أخطاء توزيع دقيقة في المحركات الرئيسية. قد يبدو تسلسل الإخراج متنوعًا دون توفير عدم القدرة على التنبؤ الخصومية المطلوبة للأدوار الحاملة للسرية.
داخل crypto.getRandomValues — يطلب المتصفح من نظام التشغيل CSPRNG، والذي يمزج بين الأجهزة وانتروبيا النظام وهو مصمم بحيث لا يمكن التنبؤ به
يمكن أن تتغير الخوارزميات الخاصة بالمحرك وسلوكها الإحصائي؛ لا يؤدي الفحص البصري أو اختبار التوزيع غير الرسمي إلى ترقية Math.random إلى مصدر تشفير. تفترض حسابات التصادم أيضًا مخرجات مستقلة من المساحة المحددة. إذا كرر المولد الحالة، أو تم تصنيفه بشكل غير صحيح أو تم استبداله بتركيبة حتمية، فقد فشل هذا الافتراض ولم تعد الصيغة تصف التنفيذ. يمكن لكل من واجهات برمجة التطبيقات (API) إنتاج سلاسل تبدو غير منتظمة على حد سواء. ويفصل بينهما نموذج التهديد: تستخدم القيم التي يجب أن تقاوم التنبؤ crypto.getRandomValues، بينما قد تستخدم عمليات المحاكاة والمراوغات غير العدائية Math.random. ويأتي الاختيار من نتيجة التنبؤ، وليس من علامات الترقيم أو التنوع الواضح في العينة.
مثال عملي - إنشاء نفس العدد من المعرفات بكل طريقة ومقارنة ما يمكن أن يستنتجه المراقب
يستخدم المولد ToolAcre UUID crypto.getRandomValues حصريًا؛ لا يستخدم مطلقًا Math.random لأن تكلفة UUID التي يمكن التنبؤ بها تكون دائمًا أعلى من تكلفة المولد الأبطأ قليلاً. يمكن قياس فرق التشفير من خلال نموذج التهديد. يجب على المهاجم الذي يريد تزوير UUIDs إما تخمين المعرف مباشرة أو كسر مولد الأرقام العشوائية. التخمين المباشر ليس المقارنة التي تحددها هذه المقالة؛ الاستنتاج المدعوم هو أن Web Crypto مخصص للعشوائية التشفيرية بينما Math.random ليس كذلك. يعرض CSPRNG وMath.random عقودًا مختلفة: الأول مصمم للعشوائية الحساسة للأمان، في حين أن الأخير لا يحمل مثل هذا الوعد. النظام الذي يستخدم Math.random للمعرفات فقد خاصية التشفير؛ يعتمد الأمان الآن على الحفاظ على سرية تسلسل UUIDs الذي تم إنشاؤه. في حالة حدوث تسرب واحد UUID، فإن جيل المستقبل بأكمله معرض للخطر.
أخطاء التوزيع التاريخية — تذكير بأن المحركات قامت بشحن Math.random من عمليات التنفيذ بمخرجات غير متساوية بشكل واضح، وتم وصفها من الناحية النوعية
إذا قام التطبيق بتخزين UUIDs في سجل أو قاعدة بيانات أو محفوظات التحكم في الإصدار، فسيكون التسرب أمرًا لا مفر منه تقريبًا. تفرض مكتبة ToolAcre استخدام crypto.getRandomValues وترفض إنشاء UUID إذا كان السياق الآمن (HTTPS أو المضيف المحلي) غير متاح. يمنع قرار التصميم هذا الرجوع الصامت إلى Math.random الذي ابتليت به العديد من عمليات التنفيذ اليدوية. في Node.js، تستخدم المكتبة وحدة التشفير؛ وفي المتصفحات، يستخدم Web Crypto API. يتطلب كلا المسارين المدعومين عشوائية قوية من حيث التشفير من النظام الأساسي. لا يقدم التنفيذ أي مطالبة بالأداء لأن المحرك والجهاز وعبء العمل يحددان التوقيت؛ عقد الضمان هو الخاصية الحاسمة للمعرفات. إن سبب استقرار معيار الصناعة على crypto.getRandomValues هو تاريخ قصير من سوء استخدام UUID. استخدمت الأنظمة المبكرة وقت النظام وواجهات الشبكة وساعات الأجهزة لإنشاء المعرفات.
ما لا يغطيه هذا هو الجودة الإحصائية لأي من المولدات لعمليات المحاكاة، وهو سؤال مختلف عن عدم القدرة على التنبؤ
تعمل إصدارات UUID المستندة إلى الوقت والعقدة والعشوائية على حل مشكلات التخصيص المختلفة؛ لا ينبغي تقديمه كإصلاح خطي لكل تصميم سابق. بالنسبة للإصدار 4، يحدد RFC 9562 الحقول العشوائية ويناقش بشكل منفصل عدم قابلية التخمين. يؤدي الترحيل بعيدًا عن Math.random إلى تغيير جودة القيم التي تم إنشاؤها حديثًا دون تغيير شكل UUID النصي. تظل المعرفات الموجودة هي مفاتيح قاعدة البيانات؛ تجديدها من شأنه كسر المراجع. يمكن للقيم الجديدة استخدام Web Crypto على الفور، بينما يجب أن يستمر التفويض في التعامل مع كل UUID القديم أو الجديد كمعرف بدلاً من إثبات الإذن. قم بتوثيق عملية القطع حتى يعرف المستجيبون للحوادث المولد الذي أنتج كل مجموعة.
الخلاصة: اختر المولد حسب التهديد، وليس حسب المظهر — يستخدم المولد ToolAcre UUID CSPRNG حصريًا، ولا يستخدم أبدًا Math.random()
يجب أن يميز التحقق من الصحة بين المعرفات القديمة (غير المناسبة للسرية) والمعرفات الجديدة (CSPRNG المدعومة). يجب أن تشير الوثائق إلى عملية الانتقال. يُنتج المولد ToolAcre فقط crypto.getRandomValues UUIDs؛ ولا يحاول التحقق من صحة أو إعادة إنشاء المعرفات من مصادر أخرى. يوضح المولد ToolAcre أفضل الممارسات من خلال رفض الرجوع إلى مصدر عشوائي أضعف. إذا لم يكن crypto.getRandomValues متاحًا، فستبلغ الأداة عن خطأ بدلاً من استخدام Math.random بصمت. وينطبق مبدأ التصميم هذا على أي نظام أمني بالغ الأهمية: الفشل بصوت عالٍ بدلاً من النجاح بهدوء مع ضمان أمني ضعيف. يجب على المطور الذي يرى "فشل إنشاء UUID: التشفير API غير متوفر" معالجة المشكلة الأساسية (الترقية إلى HTTPS، أو إصلاح السياق الآمن، أو توفير بديل مناسب). المطور الذي يتلقى UUIDs المبنية من Math.random بصمت ليس لديه أي إشارة إلى تعرض النظام للاختراق. مكتبة ToolAcre تعطي الأولوية للصدق على الراحة.