أدوات المطور · مولد UUID
هل UUID العشوائي آمن كإعادة تعيين كلمة المرور أو رمز الجلسة؟
· لماذا يهم
uuid التشفير متصفح API
يحتوي الإصدار 4 UUID من CSPRNG على الكثير من الإنتروبيا، فلماذا لا يزال مراجعو الأمان مستهجنين من الرموز المميزة UUID؟ يفصل هذا المنشور سؤال الإنتروبيا عن سؤال التصميم.
رابط إعادة التعيين الذي يستخدم الصف UUID - وهو اختصار شائع والسببين المختلفين تمامًا قد يكون غير آمن
اختصار شائع: استخدم معرف الصف UUID الخاص بالمستخدم كرمز مميز لإعادة تعيين كلمة المرور. يحتوي الجدول على عمود uuid؛ إنها فريدة من نوعها؛ من الصعب التخمين (إذا كان الإصدار 4). URL هل /reset؟ الرمز المميز=550e8400-e29b-41d4-a716-446655440000. يرفضه مراجع الأمان على الفور، ليس لأن UUID ضعيف، ولكن لأنه يجمع بين اهتمامين يجب أن يكونا مستقلين. الصف UUID مستقر وعادةً ما يكون مرئيًا للعامة (في عناوين URL وواجهات برمجة التطبيقات والسجلات). يجب أن يكون رمز إعادة الضبط مخصصًا للاستخدام مرة واحدة وسريًا. إن إعادة استخدام الصف UUID كرمز مميز يعني أن هوية المستخدم وبيانات اعتماد إعادة تعيينه لهما نفس القيمة، وتظل بيانات الاعتماد إلى الأبد بدلاً من انتهاء صلاحيتها. يمكن للمهاجم الذي يعرف معرف المستخدم إجراء إعادة التعيين. لا يزال بإمكان المستخدم الذي قام بنسخ رابط إعادة التعيين قبل خمس سنوات استخدامه. هذه عيوب في التصميم، وليست عيوب في الإنتروبيا.
فحص الإنتروبيا: 122 بتات عشوائية - لماذا لا يمكن تخمين الإصدار 4 الذي تم إنشاؤه بواسطة CSPRNG بالقوة الغاشمة
التحقق من العشوائية ضروري ولكنه غير كاف. يحتفظ الإصدار 4 بأربعة بتات للإصدار وبتتين مختلفتين، مع ترك 128 - 4 - 2 = 122 مواضع عشوائية عندما يملأ التنفيذ الحقول الأخرى بشكل عشوائي. لا يذكر هذا الاشتقاق شيئًا عن انتهاء الصلاحية أو التخزين أو الترخيص. يسأل فحص المولد ما إذا كانت هذه الحقول جاءت من CSPRNG بدلاً من Math.random أو طابع زمني. ToolAcre يفي بحدود المولد. يظل فحص التصميم خاصًا بالتطبيق: تحتاج بيانات اعتماد إعادة التعيين إلى دورة حياة منفصلة، وتمثيل مخزن في اتجاه واحد، وإبطال بعد الاستخدام الناجح، وانتهاء صلاحية يتم اختياره من سياسة مخاطر الخدمة. تؤدي إعادة استخدام معرف السجل الدائم للمستخدم إلى فشل هذا الفصل حتى عندما يتم إنشاء المعرف بشكل آمن.
فحص المولد: حيث تفشل UUID من الرموز المميزة بالفعل - الإنشاء المستند إلى Math.random، والطوابع الزمنية v1، والعناوين MAC، والبذور التي يمكن التنبؤ بها
مثال عملي: نظام إعادة تعيين كلمة المرور الذي يفشل في عمليات التحقق الثلاثة ثم يجتازها. فشل في التحقق من الإنتروبيا: يصدر الخادم رمزًا مميزًا لإعادة التعيين عبر Math.random()، معبأة كإصدار v4 UUID. يلاحظ المهاجم ثلاثة رموز ويتنبأ بالرمز الرابع. فشل فحص المولد: يستخدم الخادم الإصدار 1 UUID كرمز لإعادة التعيين، بما في ذلك الطابع الزمني للإنشاء وعنوان MAC في القيمة. يقرأ المهاجم الطابع الزمني، ويعلم متى تم إصدار إعادة التعيين، ويقوم بتضييق نافذة البحث. اجتاز فحص الإنتروبيا ولكنه فشل في فحص التصميم: يستخدم الخادم الإصدار 4 UUID من crypto.getRandomValues، ولكنه يخزنه في نص عادي في قاعدة البيانات ولا يحدد انتهاء الصلاحية. يقرأ المهاجم الذي ينتهك قاعدة البيانات الرموز المميزة لإعادة التعيين ويستخدمها لإعادة تعيين الحسابات بعد أسابيع. الشيكات الثلاثة مستقلة. يجب عليك اجتياز الثلاثة.
التحقق من التصميم: المعرف مقابل بيانات الاعتماد - لماذا إعادة استخدام المفتاح الأساسي للسجل باعتباره سرًا يجمع بين شيئين يجب تدويرهما بشكل مستقل
لا يزال نظام إعادة تعيين الرمز المميز الذي يجتاز فحوصات الإنتروبيا والمولد ولكنه يفشل في فحص التصميم (بدون تجزئة، ولا انتهاء صلاحية، ولا إبطال لكل استخدام) عرضة للخطر. التعامل مع الرمز المميز من جانب الخادم: عندما يطلب مستخدم إعادة تعيين كلمة المرور، قم بإنشاء رمز مميز عشوائي جديد (وليس الصف UUID) من crypto.getRandomValues. قم بتخزين تمثيل أحادي الاتجاه بدلاً من القيمة المقدمة، وتعيين انتهاء صلاحية خاص بالسياسة، وإبطال السجل بعد الاستخدام الناجح. عندما ينقر المستخدم على الرابط، ابحث عن المستخدم عبر البريد الإلكتروني، واجلب التجزئة المخزنة، وقارن الرمز المميز المقدم مع التجزئة، وتحقق من انتهاء الصلاحية، وقم بتنفيذ إعادة التعيين فقط إذا كان الرمز المميز صالحًا ولم تنتهي صلاحيته بعد. قم بإبطال الرمز المميز على الفور (احذفه أو ضع علامة عليه كمستخدم) بحيث لا يمكن إعادة استخدامه. لا تقم أبدًا بتسجيل الرمز المميز؛ قم بتسجيل معرف المستخدم والإجراء فقط.
التعامل مع الرمز المميز من جانب الخادم - تخزين التجزئة، وتعيين انتهاء الصلاحية، وإبطال الاستخدام، وعدم تسجيل القيمة الأولية مطلقًا
يجب ألا يظهر الرمز المميز أبدًا في رسائل الخطأ أو في قاعدة البيانات ما لم يتم تجزئته. إن تصميم المصادقة الكامل يقع خارج نطاق مقالة UUID، ولكن المبادئ تنص على ما يلي: الرمز العشوائي الذي يبلغ 122 بت ليس في حد ذاته رمز وصول. العشوائية هي الجزء السهل. يمنحك المولد ToolAcre معرفات UUID المدعومة بـ CSPRNG. الجزء الصعب هو التصميم: التجزئة قبل التخزين، وتحديد أوقات انتهاء الصلاحية، وإبطال الاستخدام، ومنع إعادة استخدام المعرفات الدائمة كأسرار مؤقتة، وتدقيق من قام بالوصول إلى ماذا ومتى. المراجع الأمني الذي يوافق على مخطط إعادة تعيين الارتباط استنادًا إلى إنتروبيا الرمز المميز وحده، يتخطى بقية التحليل. إن المطور الذي يعتقد أن CSPRNG المدعوم UUID كافٍ لرابط إعادة تعيين كلمة المرور دون التجزئة وانتهاء الصلاحية والإبطال، يقلل من شأن التهديد. العشوائية تدافع ضد التخمين. يحمي التصميم من إعادة التشغيل وانتهاء الصلاحية وسوء الاستخدام.
مثال عملي - مراجعة مخطط إعادة ضبط الارتباط مقابل كل فحص وإعادة كتابة الأجزاء الضعيفة
يقوم المولد ToolAcre بجزء العشوائية بشكل صحيح؛ يجب أن يقوم التطبيق بجزء التصميم بشكل صحيح. اختبر رمز إعادة التعيين الخاص بك مقابل جميع الاختبارات الثلاثة: هل يستخدم CSPRNG (crypto.getRandomValues، crypto.randomUUID، أو مكتبة تشفير)، وليس Math.random؟ هل للرمز وقت انتهاء الصلاحية؟ هل تم تجزئة الرمز المميز قبل تخزينه؟ هل تم إبطال الرمز المميز بعد الاستخدام؟ هل يتجنب الرمز إعادة استخدام المعرف الدائم للمستخدم كرمز مؤقت؟ إذا أجبت بنعم على كل هذه الأسئلة، فإن تصميم رابط إعادة التعيين الخاص بك سليم. المولد ToolAcre هو الجزء CSPRNG؛ والباقي هو رمز التطبيق الذي يجب عليك مراجعته بعناية. يساعدك فهم طبقات الأمان الثلاث على تدقيق مكتبات وإطارات عمل UUID التابعة لجهات خارجية. عندما تقوم بتقييم مكتبة، تأكد من أنها تستخدم CSPRNG (فحص الإنتروبيا)، وليس مصدرًا عشوائيًا ضعيفًا. تأكد من أنه يوثق المصادر التي يستخدمها ولماذا (فحص المولد).
ما لا يغطيه هذا — تصميم المصادقة الكامل، MFA وتحديد المعدل، وهو ما يهم بقدر أهمية إنتروبيا الرمز المميز
تحقق من أن التعليمات البرمجية والوثائق النموذجية تؤكد على مبادئ التصميم: التجزئة، وانتهاء الصلاحية، والإبطال (التحقق من التصميم). المكتبات التي تجتاز الاختبارات الثلاثة نادرة؛ يركز معظمهم على الإنتروبيا وحدها. يجتاز المولد ToolAcre فحص الإنتروبيا والمولد باستخدام crypto.getRandomValues. إن فحص التصميم هو مسؤوليتك؛ لا تستطيع المكتبة معرفة متطلبات انتهاء الصلاحية أو استراتيجية التجزئة الخاصة بك. عادةً ما يكشف تصحيح أخطاء نظام إعادة الارتباط المعطل عن أحد حالات الفشل الثلاثة. إذا أبلغ المستخدمون عن تلقي روابط إعادة تعيين لم تعد تعمل، فالمشكلة المحتملة هي انتهاء الصلاحية: تم إصدار الرمز المميز ولكن انتهت صلاحيته قبل أن ينقر المستخدم على الرابط. إذا تم إعادة استخدام الرموز المميزة عدة مرات، فسيتم كسر الإبطال. إذا ظهرت الرموز المميزة في رسائل الخطأ أو مخرجات التصحيح، فإن التسجيل يؤدي إلى تسريبها. إذا كانت روابط إعادة التعيين تعمل مع مستخدم واحد دون آخر، فقد يكون هناك تأخر في النسخ المتماثل لقاعدة البيانات أو مشاكل في المنطقة الزمنية في حساب انتهاء الصلاحية. إذا فشلت طلبات إعادة التعيين المشروعة بشكل عشوائي، فقد يكون CSPRNG معطلاً (نادرًا).
الخلاصة: العشوائية هي الجزء السهل - يمنحك المولد ToolAcre معرفات UUID المدعومة بـ CSPRNG؛ والباقي هو الانضباط في التصميم
ابدأ بالتسجيل: قم بتمكين سجلات التدقيق التفصيلية لإنشاء رابط إعادة التعيين والتحقق منه، ثم قم بإعادة إنتاج المشكلة وتتبع التدفق. يضمن المولد ToolAcre اجتياز أول فحصين؛ يقع استكشاف مشكلات إعادة تعيين الارتباط وإصلاحها دائمًا ضمن فئة التصميم. تتضمن أفضل الممارسات لأنظمة إعادة ضبط الإنتاج ما يلي: إنشاء رمز مميز عشوائي جديد لكل طلب إعادة تعيين، وليس إعادة استخدام الرموز المميزة القديمة. قم بتخزين تمثيل أحادي الاتجاه إلى جانب البيانات التعريفية للحساب والإنشاء، ثم اختر انتهاء الصلاحية من سياسة المخاطر الموثقة للخدمة. قم بإبطال الرمز المميز فورًا بعد نجاح عملية التحقق. تسجيل طلبات إعادة التعيين ونجاحات التدقيق. تنفيذ تحديد المعدل لمنع هجمات القوة الغاشمة. أرسل روابط إعادة التعيين عبر البريد الإلكتروني فقط، وليس SMS أو القنوات غير المشفرة. قم بإعلام المستخدم بمحاولات إعادة تعيين كلمة المرور (حتى يتمكن من اكتشاف عمليات إعادة التعيين غير المصرح بها). يمنحك المولد ToolAcre العشوائية؛ باتباع هذه الممارسات يمنحك الأمان.