أدوات المطور · مولد UUID
UUIDs المستندة إلى الاسم (الإصداران 3 و5): المعرفات الحتمية من مساحة الاسم
· خلفية
uuid التشفير متصفح API
عندما يجب أن يحصل نفس السجل الخارجي دائمًا على نفس المعرف، فلن تقوم UUID العشوائية بذلك. يقوم الإصدار 3 و5 بتقسيم UUIDs مساحة اسم واسمًا إلى معرف ثابت؛ يشرح هذا المنشور كيف ومتى يتم استخدامها.
إعادة استيراد نفس العميل مرتين - مشكلة الازدواجية التي تحلها المعرفات الحتمية
يستقبل مسار استيراد البيانات سجلات العملاء من نظام خارجي بمعرفات خارجية ثابتة داخل هذا النظام. إذا قمت بإنشاء UUID عشوائي جديد لكل عملية استيراد، فإن استيراد نفس العميل مرتين ينتج معرفين مختلفين وسجلات مكررة. يتدفق هذا الازدواجية في اتجاه مجرى النهر إلى أنظمة إعداد التقارير والفواتير والدعم. إذا قمت باشتقاق UUID من المعرف الخارجي للعميل ومساحة اسم ثابتة تمثل مصدر الاستيراد الخاص بك، فإن كل عملية استيراد تنتج نفس UUID لنفس العميل، مما يتيح لك تحديد السجلات الموجودة وتحديثها. هذه الحتمية هي السمة المميزة لمعرفات UUID v3 وv5: لا يتم إنشاؤها بشكل مستقل ولكنها مشتقة من المدخلات، وينتج نفس الإدخال دائمًا نفس UUID.
مساحة الاسم بالإضافة إلى الاسم - كيف يتم تسلسل المدخلات وتجزئتها، ولماذا تمنع مساحة الاسم التصادمات بين المصادر المختلفة
يتم اشتقاق الإصدار 3 أو الإصدار 5 UUID من ثلاثة مكونات: مساحة الاسم UUID (المحددة مسبقًا عادةً)، والاسم (أي سلسلة بايت)، وخوارزمية التجزئة (MD5 للإصدار 3، SHA-1 للإصدار 5). قم بتسلسل 16 bytes من مساحة الاسم UUID مع UTF-8 بايت من الاسم، ثم قم بتجزئة التسلسل، ثم خذ أول 16 bytes من مخرجات التجزئة، وفسر تلك البايتات على أنها UUID مع تعيين إصدار nibble على 3 أو 5. تقوم مساحة الاسم بتقسيم مساحة المعرف: معرفات UUID v5 من مساحة الاسم DNS لا تتعارض أبدًا مع معرفات UUID v5 من مساحة الاسم URL. RFC 9562 يحدد أربع مساحات أسماء محددة مسبقًا: بواسطة DNS الاسم، بواسطة URL، بواسطة OID، وبواسطة X.500 الاسم المميز. يمكن للمؤسسات إنشاء مساحة الاسم الخاصة بها عن طريق إنشاء الإصدار 4 UUID.
MD5 في الإصدار 3 وSHA-1 في الإصدار 5 - لماذا يكون التجزئة الضعيفة مقبولاً هنا، نظرًا لأن المعرف ليس عنصر تحكم أمني
يستخدم الإصدار 3 MD5 والإصدار 5 يستخدم SHA-1، والاختيارات التي يرجع تاريخها إلى تواريخ المواصفات والتطبيقات المتاحة. بالنسبة للمعرفات UUID المستندة إلى الاسم، فإن هذا التمييز غير مهم لأن وظيفة التجزئة ليست حدود أمان أو تحكم تشفير. UUID لا يثبت صحته أو نزاهته؛ إنه ببساطة يقوم بتحويل سلسلة ذات طول متغير إلى قيمة ثابتة 128 بت. نموذج الهجوم غير ذي صلة لأنه يتم تخزين UUIDs ومقارنتها كقيم غير شفافة، وليس كأدلة أو عناصر تحكم أمنية. يجب أن تستخدم التطبيقات الجديدة الإصدار 5 (SHA-1) بدلاً من الإصدار 3 (MD5)، ليس لأسباب أمنية مقنعة ولكن لأن الإصدار 5 هو المعيار الحديث والمتاح على نطاق واسع.
مساحات الأسماء المحددة مسبقًا — DNS، URL، OID وX.500، ومتى يمكنك سك مساحات الأسماء الخاصة بك
RFC 9562 يحدد بالضبط أربعة معرفات UUID محددة مسبقًا لمساحة الاسم مع تمثيلات بايت محددة: 6ba7b810-9dad-11d1-80b4-00c04fd430c8 لـ DNS، 6ba7b811-9dad-11d1-80b4-00c04fd430c8 لعناوين URL، و6ba7b812-9dad-11d1-80b4-00c04fd430c8 لمعرفات الكائنات الحية، و6ba7b814-9dad-11d1-80b4-00c04fd430c8 لـ X.500 الأسماء المميزة. سيكون الإصدار 5 UUID المشتق من مساحة الاسم DNS والاسم www.example.com متطابقين دائمًا ولن يتعارض أبدًا مع الإصدار 5 UUID من مساحة الاسم URL. يضمن استخدام مساحة اسم محددة مسبقًا إمكانية التشغيل التفاعلي: إذا كانت فرق متعددة تستخدم الإصدار 5 بشكل مستقل مع مساحة الاسم DNS، فإنها تنشئ معرفات UUID متطابقة لنفس أسماء DNS. يعد اختيار مساحة الاسم أو سكها جزءًا من تصميم المخطط.
مثال عملي - اشتقاق الإصدار 5 UUID من الناحية المفاهيمية من مساحة الاسم URL والسجل URL، خطوة بخطوة
اشتق v5 UUID من الناحية المفاهيمية من مساحة الاسم URL والاسم https://example.com/api/users/42. مساحة الاسم UUID كـ 16 bytes هي 6b a7 b8 11 إعلان 9d 11 d1 80 b4 00 c0 4f d4 30 c8. الاسم هو السلسلة UTF-8 https://example.com/api/users/42, وهي 30 bytes. قم بتسلسل وحدات بايت مساحة الاسم (16) ووحدات بايت الاسم (30) للحصول على إجمالي 46 bytes. قم بحساب تجزئة SHA-1، مما يؤدي إلى إنتاج تجزئة تبلغ 20 بايت. خذ أول 16 bytes وقم بتفسيرها على أنها UUID مع تعيين إصدار nibble على 5 وتعيين البتات المتغيرة على RFC قياسي. إن حسابها مرة أخرى باستخدام مدخلات متطابقة يؤدي إلى نفس النتيجة. يستخدم معظم المطورين مكتبة لغتهم UUID لحساب الإصدار 5.
حيث ينكسر النمط - عندما تتغير الأسماء، وعندما تكون مساحة الاسم غير متسقة بين الفرق، وعندما تكون المدخلات سرية
تفترض UUIDs المستندة إلى الاسم أن الاسم مستقر ومتسق عبر الأنظمة وعمليات الاستيراد. إذا كان نفس السجل الخارجي له أسماء مختلفة في أنظمة مختلفة، فإن إنشاء الإصدار 5 من كل اسم ينتج معرفات UUID مختلفة ويفشل في التعرف على نفس الشخص. إذا لم يتم الاتفاق على مساحة الاسم عبر الفرق (يقوم كل فريق بصياغة مساحة الاسم الخاصة به لما هو في الواقع نفس المصدر)، فإنهم يقومون بإنشاء معرفات UUID مختلفة ويفشلون في مطابقة السجلات. إذا كان الإدخال عبارة عن بيانات حساسة، فإن إنشاء الإصدار 5 UUID يعني أن UUID هي قيمة عامة وحتمية يمكن لأي شخص البحث عنها إذا كان يعرف المدخلات. تنكسر الحتمية عندما تتغير المدخلات أو عندما تكون تعريفات مساحة الاسم غير متناسقة.
ما لا يغطيه هذا — يستمد المولد ToolAcre من CSPRNG، لذا تحتاج المعرفات المستندة إلى الاسم إلى مكتبة UUID الخاصة بلغتك
ToolAcre ينشئ v4 UUIDs فقط، مأخوذة من المولد الآمن للتشفير في المتصفح من أجل الاستقلال. يتطلب اشتقاق UUID القائم على الاسم مكتبة UUID الخاصة بلغتك أو تطبيقًا يحسب SHA-1 وينسق النتيجة بشكل صحيح. يشرح هذا المنشور المفهوم وحالات الاستخدام؛ يعد تنفيذ الجيل الخامس أمرًا سهلاً بأي لغة مع إمكانية الوصول إلى مكتبات التشفير القياسية. آليات اشتقاق الإصدار الخامس بسيطة؛ ويتمثل التحدي في دمجها في مخطط النظام حيث تكون مساحة الاسم مستقرة، والاسم متسق، والنهج موثق جيدًا لفريقك. يجب على فرق التطوير توثيق اختيارات مساحة الاسم.
الوجبات الجاهزة: حتمية عندما تحتاج إليها، عشوائية بخلاف ذلك - استخدم الإصدار 5 للتعيينات المستقرة والمولد ToolAcre لكل شيء لا يمكن تخمينه
استخدم الإصدار 5 للتعيينات الثابتة بين المعرفات الخارجية وسجلاتك الداخلية. تمنع الحتمية الواردات المكررة وتجعل السجلات المطابقة عبر الأنظمة واضحة وموثوقة. لا تستخدم UUIDs المستندة إلى الأسماء للمعرفات التي يجب أن تكون غير قابلة للتخمين أو للسيناريوهات التي تتطلب سرية وأسرارًا قوية. ToolAcre ينشئ معرفات UUID عشوائية للإصدار 4 للمعرفات التي يجب أن تكون مستقلة ومتميزة دون إمكانية التنبؤ. عندما تحتاج أنظمتك إلى معرفات حتمية تقوم بتعيين المدخلات إلى معرفات ثابتة، يمكن لمكتبة UUID الخاصة بك حسابها. تعتبر الحتمية ميزة قوية عند التحكم في الإدخال.