خطوتان لا تعنيان بالضرورة عاملين؛ فكلمة المرور ورمز PIN كلاهما معرفة. قد تفعّل القياسات الحيوية أداة المصادقة، لكنها لا تضمن وحدها إخفاء الهوية أو مقاومة التصيد.
مقارنة الآليات لا عدد الشاشات
يميز NIST بين المعرفة والحيازة والخصائص الحيوية. يمكن تمرير رمز لمرة واحدة يُدخل يدويًا عبر موقع مزيف؛ لذلك لا يعادل SMS أو TOTP مصادقة مقاومة للتصيد. يربط مفتاح المرور المطبق بشكل صحيح الاستجابة بالخدمة. وتعتمد الضمانات أيضًا على التحقق المحلي والنسخ الاحتياطي والمزامنة.
فهم دور القياسات الحيوية
في WebAuthn يمكن أن يحدث التعرف الحيوي داخل أداة المصادقة؛ ولا تُرسل البيانات الحيوية إلى خدمة الويب المستقبلة. وقد يستخدم التحقق المحلي رمز PIN. يختلف حضور المستخدم (UP) عن التحقق منه (UV). يجب على الخادم فحص الاستجابة وفق البروتوكول؛ شاشة التعرف على الوجه وحدها لا تكفي.
حماية دورة الحياة
خطط للتسجيل وإضافة وسيلة وفقدان الجهاز والإلغاء واسترداد الحساب. قيّم الإتاحة والبدائل التي قد تضعف المسار الرئيسي. لا تحل المصادقة محل صلاحيات البيانات والعمليات.
المصادر
المراجعة التحريرية: 1 نوفمبر 2026.
فصل عامل ثانٍ عن مقاومة التصيّد الاحتيالي.
تشير NIST إلى أن رمزًا لمرة واحدة يتم إدخاله يدويًا يمكن إعادة توجيهه عبر صفحة مُنتحلة، لذا فإن وجوده وحده لا يجعل تسجيل الدخول مقاومًا للتصيّد الاحتيالي. يربط WebAuthn المُدمج بشكل صحيح الاستجابة بالخدمة الأصلية. ويظل استعادة الحساب وسيلةً لتعزيز الأمان.
- عرض قائمة بالتطبيقات التي لا تزال تقبل الرسائل النصية القصيرة أو الرموز أو الموافقة التي يمكن تجاوزها، مع إعطاء الأولوية للحسابات ذات الامتيازات.
- اختبار التسجيل وفقدان الجهاز وإلغاء المصادقة من خلال تجربة مستخدم حقيقية.
- قياس تغطية عامل المقاومة والاحتفاظ بالاستثناءات المؤرخة مع أصحابها.
المصدر الأساسي: NIST SP 800-63B-4. المنهج المرتبط: اقرأ الدليل العملي.
مفاتيح المرور: الاستعداد لتغيير النطاق وRP ID
فصل الحساب وأصل الويب وRP ID لتجنب إعادة ربط بيانات الاعتماد بصمت.
- سجّل الأصول القديمة والجديدة وRP ID والحسابات المرتبطة. تطابق اسم الحساب لا يجعل مفتاح المرور صالحاً لـRP ID آخر. افحص التركيبات المسموحة في WebAuthn ومسارات الوصول المتاحة أثناء الانتقال.
- في بيئة اختبار مصرح بها افحص التحدي والأصل وRP ID وربط الحساب بمكتبة مناسبة. جرّب أصلاً غير متوقع وتحدياً معاداً. تغيير RP ID يتطلب تسجيلاً جديداً موثّقاً؛ نسخ صف لا ينقل المفتاح.
- اختبر مستخدماً يملك الاعتماد القديم فقط والاسترداد والجلسات المفتوحة. حدّد فتح المسارات وإيقافها مع رجوع مختبر. التسجيل في النطاق الجديد لا يثبت إلغاء كل الجلسات القديمة.
حالة قبول قابلة للتكرار
مثال افتراضي: البيانات لا تصف عميلاً أو نتيجة مرصودة.
عرض بيانات الحالة
{
"old_origin": "https://login.old.example",
"old_rp_id": "old.example",
"new_origin": "https://login.new.example",
"new_rp_id": "new.example",
"same_service_account": true,
"expected": "authenticated_new_registration"
}القرار المتوقع
مثال افتراضي: الحساب نفسه، لكن old.example يصبح new.example مع RP ID مختلف. لا يعاد ربط الاعتماد القديم بصمت؛ يتبع التسجيل الجديد المسار الموثّق المخطط.
هل يمكن تغيير RP ID لمفتاح المرور بتعديل قاعدة البيانات؟
لا. RP ID جزء من النطاق المتحقق منه للاعتماد. أعد تسجيلاً صالحاً للنطاق الجديد وربط حساب موثّقاً.
المصدر الأساسي: W3C — Web Authentication Level 2. المنهج المرتبط: اقرأ الدليل العملي.
postMessage: التحقق من المصدر والنافذة والأمر
تحديد عقد رسائل iframe أو نافذة منبثقة يرفض المرسلين والبيانات غير المتوقعة.
- سجّل أصولاً دقيقة والنافذة المتوقعة وأنواع الرسائل. استخدم targetOrigin محدداً للبيانات الحساسة. يشمل الأصل البروتوكول والمضيف والمنفذ؛ البحث عن جزء من اسم نطاق لا يثبت هوية المرسل.
- قارن event.origin وevent.source في هذا التكامل بالنافذة المتوقعة. افحص البنية والقيم المسموحة وحالة العملية. تعامل مع المحتوى كبيانات دون eval أو إدراج HTML. الأصل المعتمد لا يحل محل تفويض الخادم.
- اختبر نطاقاً مشابهاً ومنفذاً مختلفاً ونافذة أخرى من الأصل نفسه وحقولاً غير صحيحة ورسائل بعد الإغلاق. أزل المستمعين غير اللازمين وأبطل التبادلات المنتهية. استخدم أصلاً سبق اعتماده للرد حتى بعد تنقل النافذة.
حالة قبول قابلة للتكرار
مثال افتراضي: البيانات لا تصف عميلاً أو نتيجة مرصودة.
عرض بيانات الحالة
{
"allowed_origin": "https://widget.example",
"observed_origin": "https://widget.example",
"expected_window": "active_iframe",
"observed_window": "another_window",
"payload_schema_valid": true,
"expected": "reject_without_effect"
}القرار المتوقع
مثال افتراضي: https://widget.example أصل معتمد لكن event.source نافذة أخرى. العقد يتطلب iframe النشطة: ارفض الرسالة دون إصدار أمر.
المصدر الأساسي: MDN — Window.postMessage. المنهج المرتبط: اقرأ الدليل العملي.
الهوية: العوامل والجلسات والاسترداد
عاملان: فحص البروتوكول لا الواجهة فقط
تختلف صلة رموز الإدخال وموافقات push واستجابات WebAuthn بالخدمة. قد تفعّل القياسات الحيوية أداة المصادقة، لكنها لا تستبدل التحقق التشفيري من الاستجابة.
- تفعيل محلي — PIN أو قياس حيوي بحسب الأداة.
- توقيع الاستجابة — مفتاح مرتبط بالخدمة وتحدٍّ مستلم.
- تحقق الخادم — التحدي والأصل والتوقيع والمؤشرات.
- تفويض العملية — حقوق الكائن والإجراء.
- ملاحظة UP وUV بشكل منفصل.
- فحص شروط المزامنة وعدم قابلية التصدير المطلوبة.
- تجربة فقدان الوسيلة وإضافة أخرى من جلسة قائمة.
تم التحقق من المصادر في · NIST SP 800-63B-4 · final publication NIST · Authenticator Event Management W3C · WebAuthn Level 3
الإضافات: الأذونات والوصول
الملاحظات المرجعية المفصّلة متاحة باللغة الإنجليزية في هذه النسخة.
Robust authentication does not describe extension access
Phishing resistance does not remove the need to examine what runs in the browser after a session opens. A manifest provides clues about cookies, scripting, debugging and identity without establishing collection.
- Test approved extensions in a profile dedicated to sensitive operations.
- For identity, inspect OAuth scopes and recipients; this permission does not enumerate identity-provider rights.
- Distinguish session revocation, token revocation, extension disablement and native-component removal.
Read the permission directory and manifest examples →
Google Chrome · Stay secure · Documentation consulted 2026-10-23; browser behaviour remains version-dependent