لماذا مفاتيح المرور آمنة ── دليل مرسوم لـ«مصادقة لا ترسل سرّاً»

خبر أنّ «كلمات المرور تسرّبت من خدمة كبرى أخرى» لم يعد يفاجئ أحداً. نفّذوا تدريبات تصيّد كلّ سنة، وعدد من يقع فيها لا يصل إلى الصفر قطّ. «لا تعيدوا استخدام كلمات المرور، اجعلوها طويلة، والتغيير الدوريّ… لم تعد بحاجة إليه» — حتّى النصيحة تقلّبت.

مفاتيح المرور (passkeys)، التي انتشرت بسرعة خلال السنوات القليلة الماضية، طريقة مصادقة تدفع بها Apple وGoogle وMicrosoft معاً جواباً على هذا الوضع.¹ كثيراً ما تُقدَّم بأنّها «مريحة — يمكنكم تسجيل الدخول ببصمة الإصبع أو الوجه» — لكن ذلك ليس جوهر الأمر. القيمة الحقيقيّة لمفتاح المرور أنّه ينقل أساس الأمن من «يقظة الإنسان» إلى «بنية البروتوكول».

• كلمات المرور تتسرّب لأنّ المستخدمين مهملون، فلنُدرّبهم → البشر يخطئون دائماً
• لنُدرّب الناس على اكتشاف المواقع المزيّفة → يمكن بناء موقع مزيّف يستحيل اكتشافه
• مع مفتاح المرور → لا سرّ يُرسل أصلاً، ولا يمكن إنتاج توقيع على موقع مزيّف

يعمل هذا المقال بالرسوم على سبب أمان مفاتيح المرور، بادئاً ممّا انكسر في كلمات المرور. ثمّ يجيب مباشرة على الأسئلة الواضحة — «هل مفاتيح المرور المتزامنة آمنة حقّاً؟» و«هل لها نقاط ضعف؟» — ويختم بترتيب الأساسيّات العمليّة لنشر مفاتيح المرور في تطبيقات الويب وبيئات Windows.

1. الخلاصة أوّلاً

أسباب أمان مفاتيح المرور تُختصَر في ثلاث نقاط.

1. لا سرّ يوجد على الخادم. كلّ ما يخزّنه الخادم هو المفتاح العامّ، وهي معلومات آمنة إن تسرّبت. حتّى إن استُخرجت قاعدة البيانات بأكملها، لا «مادّة لانتحال الشخصيّة» يحملها المهاجم إلى بيته.²
2. السرّ لا يسير على الشبكة قطّ. كلّ ما يُرسل عند تسجيل الدخول توقيع على قيمة عشوائيّة لمرّة واحدة (التحدّي). لأنّ المفتاح الخاصّ لا يغادر مصادِق الجهاز قطّ، التنصّت أو الترحيل في أيّ موضع على المسار لا يُنتج سرّاً.²
3. لا يمكن إنتاج توقيع على موقع مزيّف. مفتاح المرور مربوط بنطاق الموقع، ويفرض المتصفّح مطابقة النطاق. حتّى إن خُدع مستخدم بموقع مزيّف، لا يظهر مفتاح المرور للموقع الحقيقيّ مرشَّحاً أصلاً، وحتّى لو رُحِّل توقيع بطريقة ما، يرفضه التحقّق.³

هذه ليست ثلاث حيل مستقلّة — بل كلّها نتائج تتبع تغييراً تصميميّاً واحداً: الانتقال من مصادقة تشترك في سرّ وترسله، إلى مصادقة تُثبت حيازة سرّ عبر توقيع. لنأخذها بالترتيب.

علاقة المصطلحات ── مفاتيح المرور وWebAuthn وFIDO2 وCTAP

هذا المجال مليء بالمصطلحات، ومقالات مختلفة تستخدمها بنطاقات مختلفة، فلنثبّت العلاقات أوّلاً. مفتاح المرور ليس بروتوكولاً جديداً — إنّه «اسم» أُلصق بتركيبة معايير قائمة.²¹

جدول 1: مفتاح المرور اسم يُعطى فوق أساس FIDO2 — ليس اسم معيار بذاته

بعبارة أخرى، «دعم مفاتيح المرور» يترجم، بلغة التنفيذ، إلى «تنفيذ WebAuthn». CTAP طبقة يتولاها المتصفّح ونظام التشغيل نيابة عنكم حين يُستخدم مصادِق خارجيّ، لذا من يبنون تطبيقات ويب لا يلمسونه مباشرة.

خريطة المعرفة لهذه المقالة

مفتاح المرور اعتماد مبنيّ على التشفير بالمفتاح العام فوق معياري WebAuthn وCTAP (معاً FIDO2): لا يخرج المفتاح الخاصّ من أداة المصادقة، ولا يُودَع لدى الخادم إلا المفتاح العام الذي لا يُساء استخدامه إن تسرب. يُنشَأ مفتاح المرور مربوطاً بنطاق الموقع (RP ID)، لذا لا ينعقد التوقيع أصلاً على موقع مزيّف فيُمنَع التصيّد بنيويّاً. مفتاح المرور المتزامن ينال مقاومة الفقد مقابل الاعتماد على حساب سحابيّ، أمّا المقيَّد بالجهاز فيحبس المفتاح في العتاد. بعد إدخال مفاتيح المرور يصير محور العمل تضييق وسائل الاحتياط المتزامنة وتعزيز مسار استرداد الحساب.

flowchart LR
    accTitle: خريطة معرفة لماذا مفاتيح المرور آمنة
    accDescr: مخطّط يبيّن قيام مفتاح المرور على WebAuthn وFIDO2 وCTAP والتشفير بالمفتاح العام، وأنّ الربط بالنطاق عبر RP ID يمنع التصيّد بنيويّاً، والفرق بين النوع المتزامن والنوع المقيَّد بالجهاز ونقطة العطل الواحدة لكلّ منهما، وموقعه بوصفه MFA مقاوماً للتصيّد، وعلاقات المخاطر المتبقية (المسار الاحتياطيّ واسترداد الحساب وسرقة الجلسة)
    passkey["مفتاح المرور (passkey)"]
    webauthn["WebAuthn"]
    fido2["FIDO2"]
    public_key_cryptography["التشفير بالمفتاح العام"]
    ctap["CTAP"]
    authenticator["أداة المصادقة"]
    tpm["TPM"]
    windows_hello["Windows Hello"]
    fido2_security_key["مفتاح أمان"]
    device_bound_passkey["مفتاح مرور مقيَّد بالجهاز"]
    webauthn_secure_context["متطلّب السياق الآمن (HTTPS)"]
    webauthn_challenge["تحدٍّ (عدد عشوائيّ لمرّة واحدة)"]
    rp_id["RP ID (معرّف Relying Party)"]
    phishing["تصيّد (phishing)"]
    aitm_phishing["تصيّد من نوع AiTM (وسيط)"]
    credential_database_breach["تسريب قاعدة بيانات الاعتمادات"]
    password_authentication["مصادقة بكلمة المرور"]
    password_reuse["إعادة استخدام كلمة المرور (هجوم بالقائمة)"]
    account_takeover["الاستيلاء على الحساب"]
    session_cookie_theft["سرقة cookie الجلسة"]
    totp["كلمة مرور لمرّة واحدة (TOTP)"]
    phishing_resistant_mfa["MFA مقاوم للتصيّد"]
    entra_id["Microsoft Entra ID"]
    synced_passkey["مفتاح مرور متزامن"]
    platform_credential_vault["خزينة بيانات اعتماد المنصّة"]
    nist_aal3["NIST AAL3 (مستوى ضمان أداة المصادقة 3)"]
    platform_account_hardening["تعزيز حماية حساب المنصّة"]
    account_recovery_abuse["إساءة استخدام مسار استرداد الحساب"]
    account_recovery_hardening["تعزيز التحقّق من الهويّة في مسار الاسترداد"]
    fallback_credential["وسيلة مصادقة احتياطيّة متزامنة"]
    fallback_retirement["تضييق وسائل الاحتياط وفق خطّة"]
    passkey -->|"يستخدم"| webauthn
    passkey -->|"يستخدم"| fido2
    passkey -->|"يستخدم"| public_key_cryptography
    fido2 -->|"يستخدم"| webauthn
    fido2 -->|"يستخدم"| ctap
    passkey -->|"يستخدم"| authenticator
    authenticator -.->|"يستخدم"| tpm
    windows_hello -.->|"يستخدم"| tpm
    passkey -.->|"يستخدم"| windows_hello
    passkey -.->|"يستخدم"| fido2_security_key
    device_bound_passkey -->|"يستخدم"| authenticator
    webauthn -->|"يشترط"| webauthn_secure_context
    webauthn -->|"يستخدم"| webauthn_challenge
    passkey -->|"يشترط"| rp_id
    rp_id -->|"يمنع"| phishing
    passkey -->|"يمنع"| phishing
    passkey -->|"يمنع"| aitm_phishing
    public_key_cryptography -->|"يخفّف"| credential_database_breach
    password_authentication -.->|"قد يسبّب"| credential_database_breach
    password_authentication -.->|"قد يسبّب"| phishing
    password_authentication -.->|"قد يسبّب"| password_reuse
    password_reuse -.->|"قد يسبّب"| account_takeover
    aitm_phishing -.->|"قد يسبّب"| session_cookie_theft
    totp -->|"غير موصى به لـ"| phishing_resistant_mfa
    passkey -->|"موصى به لـ"| phishing_resistant_mfa
    entra_id -.->|"يستخدم"| passkey
    passkey -.->|"يُكوَّن بـ"| entra_id
    synced_passkey -->|"يُحفظ في"| platform_credential_vault
    synced_passkey -->|"لا يتوافق مع"| nist_aal3
    device_bound_passkey -.->|"موصى به لـ"| nist_aal3
    platform_credential_vault -.->|"قد يسبّب"| account_takeover
    platform_account_hardening -->|"موصى به لـ"| account_takeover
    account_recovery_abuse -.->|"قد يسبّب"| account_takeover
    account_recovery_hardening -->|"موصى به لـ"| account_recovery_abuse
    fallback_credential -.->|"قد يسبّب"| account_takeover
    fallback_retirement -->|"موصى به لـ"| fallback_credential
    session_cookie_theft -->|"قد يسبّب"| account_takeover
    passkey -->|"غير موصى به لـ"| session_cookie_theft

في المخطّط، يشير الخطّ المتّصل إلى علاقة قائمة دائماً، ويشير الخطّ المتقطّع إلى علاقة مشروطة (شروط قيامها مذكورة في شرح كلّ علاقة في الصفحة التفصيليّة). القائمة الكاملة للعلاقات (المجموع 38، مع الأدلّة ودرجة اليقين) وتعريفات المفاهيم الرئيسة مجمّعة في صفحة تفاصيل خريطة المعرفة (باليابانية). البيانات: JSON-LD / Turtle

2. ما الذي انكسر في مصادقة كلمة المرور

الطريق المختصر لفهم سبب أمان مفاتيح المرور التفكير في نقاط ضعف كلمة المرور من حيث «المكان». مع مصادقة كلمة المرور، السرّ نفسه يسافر المسار بأكمله في كلّ مرّة تصادقون.

sequenceDiagram
    participant U as المستخدم
    participant B as المتصفّح
    participant S as الخادم
    Note over U: يحمل السرّ (كلمة المرور) في رأسه<br/>【الضعف ①】قابل للتخمين ويُعاد استخدامه
    U->>B: يُدخل كلمة المرور
    Note over B: 【الضعف ②】يمكن إدخالها في موقع مزيّف<br/>بالطريقة نفسها (لا تُميَّز بالشكل)
    B->>S: يرسل كلمة المرور نفسها
    Note over B,S: 【الضعف ③】السرّ يسير على المسار<br/>يحميه TLS لكنّه يعود نصّاً صريحاً عند الطرف
    S->>S: يطابقه مع التجزئة المخزَّنة
    Note over S: 【الضعف ④】أسرار كلّ المستخدمين (تجزئاتها) تتجمّع<br/>والتسرّب يصير هدفاً للقوّة الغاشمة دون اتّصال

الشكل 1: في مصادقة كلمة المرور، يوجد السرّ نفسه عبر المسار بأكمله

من وجهة نظر مهاجم، هذه بنية ذات أهداف كثيرة سهلة.

• الضعف ① (المستخدم): كلمة المرور لا تزيد قوّة عمّا يمكن تذكّره، وتُعاد استخدامها عبر مواقع متعدّدة. تسرّب في موضع واحد ينتشر إلى كلّ الحسابات (هجمات قائمة كلمات المرور).
• الضعف ② (لحظة الإدخال): أعدّوا موقعاً مزيّفاً لا يُميَّز عن الحقيقيّ، فيسلّم المستخدم السرّ طوعاً (تصيّد).
• الضعف ③ (المسار): يجعل TLS التنصّت على المسار نفسه صعباً، لكن ذلك بلا معنى متى أُدرجت «نقطة ترحيل بمظهر شرعيّ» (AiTM، يُناقَش لاحقاً).
• الضعف ④ (الخادم): حتّى مخزَّنة كتجزئات، متى تسرّبت قاعدة البيانات يمكن كسرها بالقوّة الغاشمة دون اتّصال. أضعف كلمات المرور تسقط أوّلاً.

الجواب التقليديّ، المصادقة متعدّدة العوامل، يقول «فلنُضِف رمزاً لمرّة واحدة — SMS أو TOTP» — لكن هذا لا يغيّر بنية إرسال سرّ مشترك. TOTP يجعل الخادم وتطبيق المصادقة يشتركان في البذرة نفسها (سرّ)، والرمز السداسيّ المولَّد يمكن، في النهاية، أن يكتبه المستخدم في موقع مزيّف. في الواقع، تصيّد AiTM (Adversary-in-the-Middle)، حيث يرحّل موقع مزيّف في الوقت الحقيقيّ إلى الخادم الحقيقيّ، يهزم هذا بتمرير زوج كلمة المرور زائد الرمز لمرّة واحدة مباشرة. لهذا تحديداً تسرد CISA (وكالة الأمن السيبرانيّ والبنية التحتيّة الأمريكيّة) طريقتين فقط بوصفهما «MFA مقاوم للتصيّد» — FIDO/WebAuthn والمصادقة القائمة على PKI مثل البطاقات الذكيّة (PIV/CAC) — وتضع FIDO بينها المعيار الذهبيّ.⁴

بعبارة أخرى، المشكلة ليست «قوّة» كلمة المرور — بل بنية الاشتراك في سرّ وإرساله في كلّ مصادقة ذاتها.

3. هويّة مفتاح المرور ── إثبات الحيازة دون إرسال السرّ

مفتاح المرور بيانات اعتماد قائمة على التشفير بالمفتاح العامّ، مبنيّة على معيارين: WebAuthn من W3C وCTAP من تحالف FIDO (معاً FIDO2).²¹ قد يبدو صعباً، لكن البنية بسيطة.

flowchart LR
    subgraph DEV["جهاز المستخدم"]
        AUTH["المصادِق (خزنة)<br/>Windows Hello / Face ID /<br/>قفل شاشة Android / مفتاح أمن"]
        SK["المفتاح الخاصّ<br/>لا يخرج من هنا قطّ"]
        BIO["بصمة الإصبع والوجه وPIN<br/>= لفتح باب الخزنة فقط<br/>وهذا أيضاً لا يخرج"]
        AUTH --- SK
        BIO -->|"مطابقة محلّيّة"| AUTH
    end
    subgraph SRV["الخادم"]
        PK["المفتاح العامّ<br/>آمن إن تسرّب<br/>معلومات «للتحقّق فقط»"]
    end
    SK -.->|"زوج رياضيّ<br/>(جانب صنع التوقيع)"| PK

الشكل 2: كيان مفتاح المرور زوج مفاتيح لكلّ موقع. الجانب السرّيّ لا يغادر الجهاز، والخادم لا يحمل إلا المفتاح العامّ للتحقّق

• المفتاح الخاصّ هو مفتاح جانب صنع التوقيع، ويُحفَظ في المصادِق داخل الجهاز (Windows Hello، وFace ID/Touch ID على iPhone، وقفل شاشة Android، أو مفتاح أمن مثل YubiKey)، ولا يخرج.
• المفتاح العامّ هو مفتاح جانب التحقّق من التوقيع فقط، وهذا ما تودعونه لدى الخادم. حساب المفتاح الخاصّ عكسياً من المفتاح العامّ مستحيل حسابيّاً، لذا هي معلومات لا يضير تسرّبها.
• البيانات الحيويّة مثل البصمة والوجه تُستخدم فقط لفتح باب الخزنة محلّيّاً، وهذه أيضاً لا تغادر الجهاز. لا تُرسل بيانات حيويّة إلى الخادم قطّ.¹

التسجيل: تسليم المفتاح العامّ «فقط»

تدفّق تسجيل مفتاح مرور في موقع.

sequenceDiagram
    participant S as الخادم (example.com)
    participant B as المتصفّح
    participant A as المصادِق
    S->>B: طلب تسجيل (تحدٍّ عشوائيّ + معلومات الموقع)
    B->>A: اصنع مفتاحاً لهذا الموقع (example.com)
    A->>A: تحقّق من الهويّة ببصمة أو وجه أو PIN (محلّيّ)
    A->>A: توليد زوج مفاتيح جديد<br/>المفتاح الخاصّ يُحفَظ داخليّاً
    A->>B: المفتاح العامّ + credential ID (بطاقة اسم المفتاح)
    B->>S: إرسال المفتاح العامّ + credential ID
    S->>S: الحفظ كمفتاح عامّ لهذا الحساب
    Note over S: ما تلقّاه الخادم<br/>«معلومات آمنة إن تسرّبت» فقط

الشكل 3: عند التسجيل، ما يسير على الشبكة ويُحفَظ على الخادم هو المفتاح العامّ فقط

المهمّ أنّ زوج المفاتيح يُنشأ في هذه اللحظة مربوطاً بنطاق الموقع (RP ID). مفتاح مرور صُنع لـ example.com لا يُستخدم إلا في موقع example.com (RP ID على مستوى النطاق، لذا يمكن استخدامه من صفحات نطاقات فرعيّة تحت النطاق نفسه مثل login.example.com، لكن ليس من نطاق غير ذي صلة). هذا الربط أساس مقاومة التصيّد التي تُناقَش لاحقاً.³

كذلك يُنشأ زوج المفاتيح جديداً لكلّ موقع في كلّ مرّة. مفتاحا مرور الموقع أ والموقع ب غير مرتبطين رياضيّاً، لذا مفهوم «إعادة الاستخدام» نفسه غير موجود، ولا يصيران مادّة لمضاهاة المستخدمين عبر المواقع.

المصادقة: إعادة توقيع لتلك اللحظة فقط

تدفّق تسجيل الدخول. قارنوه بمصادقة كلمة المرور (الشكل 1).

sequenceDiagram
    participant S as الخادم (example.com)
    participant B as المتصفّح
    participant A as المصادِق
    S->>B: طلب تسجيل دخول (تحدٍّ عشوائيّ لتلك اللحظة)
    B->>A: طلب توقيع لـ example.com
    A->>A: تحقّق من الهويّة ببصمة أو وجه أو PIN (محلّيّ)
    A->>A: صنع توقيع بالمفتاح الخاصّ<br/>يضمّن التحدّي + الأصل + تجزئة RP ID
    A->>B: التوقيع (ليس المفتاح الخاصّ نفسه)
    B->>S: إرسال التوقيع
    S->>S: التحقّق من التوقيع بالمفتاح العامّ المخزَّن<br/>وتأكيد التحدّي والأصل وRP ID أيضاً
    Note over B,S: ما يسير على المسار توقيع لمرّة واحدة فقط<br/>سرقته لا تفيد في تحدّي المرّة التالية

الشكل 4: عند المصادقة أيضاً لا ينتقل السرّ. ما يسير «وثيقة إثبات لتلك اللحظة فقط»

يُخرج الخادم قيمة عشوائيّة جديدة (تحدّياً) في كلّ مرّة، ويوقّع المصادِق على «ذلك التحدّي + الأصل الذي يراه المتصفّح الآن + تجزئة RP ID». يتحقّق الخادم من التوقيع بالمفتاح العامّ المخزَّن، ويؤكّد أنّ التحدّي هو ما أصدره، وأنّ الأصل وRP ID يخصّان موقعه.⁵

كنتيجة لهذا التصميم، اثنان من الأسباب الثلاثة في المقدّمة قائمان أصلاً.

• لا سرّ على الخادم: المخزَّن المفتاح العامّ فقط. حتّى إن تسرّب لا يستطيع المهاجم صنع توقيع، فلا يمكن «حمله وكسره» كتجزئة كلمة مرور.
• السرّ لا يسير: سرقة التوقيع على المسار لا تفيد، لأنّ التحدّي لمرّة واحدة فلا يُعاد استخدامه (إعادة تشغيل).

الثالث المتبقّي، «لا ينعقد التوقيع على موقع مزيّف»، أكبر ميزة لمفاتيح المرور. نفرد له قسماً.

4. لماذا لا ينعقد التصيّد «بنيويّاً»

ينجح التصيّد ضدّ كلمات المرور لأنّ السرّ الحقيقيّ يمكن إدخاله في موقع مزيّف. البشر لا يميّزون example.com عن examp1e.com (خصوصاً عند الإرهاق)، وحقل إدخال كلمة المرور يعمل بالطريقة نفسها على أيّ الموقعين.

مع مفاتيح المرور، يجري هذه المطابقة المتصفّح آليّاً لا الإنسان. بحسب مواصفة WebAuthn، لا يستطيع المتصفّح استدعاء المصادِق إلا حين يتطابق «نطاق الأصل المعروض الآن» مع «RP ID لمفتاح المرور».³ نرسم ما يحدث عند الوصول إلى موقع مزيّف.

sequenceDiagram
    participant U as المستخدم
    participant B as المتصفّح
    participant P as موقع مزيّف (examp1e.com)<br/>وكيل AiTM يرحّل إلى الحقيقيّ
    participant S as الخادم الحقيقيّ (example.com)
    U->>P: الوصول إلى شاشة تسجيل دخول متطابقة الشكل
    P->>S: (في الخفاء) بدء معالجة تسجيل الدخول الحقيقيّة
    S->>P: التحدّي
    P->>B: ترحيل التحدّي وطلب توقيع
    B->>B: الأصل الحاليّ هو examp1e.com<br/>لا يمكن عرض مفتاح مرور example.com مرشَّحاً
    B--xP: لا يُصنَع توقيع (لا سبيل لخداع المستخدم)
    Note over B,S: حتّى لو صُنع توقيع بطريقة ما،<br/>يُضمَّن examp1e.com في التوقيع<br/>فيسقط حتماً في تحقّق الخادم الحقيقيّ

الشكل 5: يخترق تصيّد AiTM كلمة المرور زائد الرمز لمرّة واحدة، لكن مع مفاتيح المرور لا ينعقد عند مرحلة التوقيع

لاحظوا أنّ الدفاع مزدوج.

1. لا يظهر مرشَّحاً: لا يسرد المتصفّح إلا مفاتيح المرور ذات RP ID المطابق للأصل. على نطاق مزيّف لا يظهر مفتاح مرور الموقع الحقيقيّ خياراً، فلا يستطيع المستخدم حتّى «استخدامه سهواً».
2. لا يمرّ التوقيع: يشمل موضوع التوقيع الأصل الذي أكّده المتصفّح وتجزئة RP ID. يطابق الخادم الحقيقيّ هذا عند التحقّق، لذا يُرفض حتماً توقيع صُنع على أصل آخر.⁵

كانت مكافحة تصيّد كلمات المرور تعتمد على جهد الإنسان «ينظر المستخدم جيّداً إلى عنوان URL». مع مفاتيح المرور لا يحتاج المستخدم إلى اكتشاف الموقع المزيّف أصلاً. هذا المعنى الدقيق لعبارة «مقاوم للتصيّد (phishing-resistant)»، وسبب المعاملة الخاصّة التي تمنحها CISA وNIST (المعهد الوطنيّ الأمريكيّ للمعايير والتقنية) لطريقة FIDO/WebAuthn.⁴⁶

نرتّب ما سبق حسب أسلوب الهجوم.

جدول 2: مقارنة المقاومة حسب أسلوب الهجوم. كلّ «○» لمفتاح المرور تأتي من البنية لا من التشغيل أو الانتباه

5. هل «مفاتيح المرور المتزامنة» آمنة؟

بعد قراءة الشرح حتّى هنا، ينبع سؤال طبيعيّ. «قلتم إنّ المفتاح الخاصّ لا يغادر الجهاز، فلماذا يعمل مفتاح مرور صُنع على iPhone على iPad أيضاً» — سؤال جيّد، والجواب «لمفاتيح المرور نوعان».

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

جدول 3: جدول سريع للمتزامن والمربوط بالجهاز. الاختيار يُحسَم بأيّهما تأخذون: القوّة أمام الفقدان أم القدرة على إدارة موضع المفتاح

flowchart TB
    subgraph SYNC["مفتاح مرور متزامن (افتراضيّ المستهلك)"]
        S1["سلسلة مفاتيح iCloud /<br/>مدير كلمات مرور Google /<br/>مديرو كلمات مرور مثل 1Password"]
        S2["مزامنة مشفَّرة من طرف إلى طرف<br/>بين أجهزة الحساب نفسه<br/>المشغّل أيضاً لا يقرأ المحتوى"]
        S3["المزيّة: قويّ أمام تغيير الجهاز والفقدان<br/>انتبهوا: يلزم دفاع الحساب السحابيّ نفسه"]
        S1 --> S2 --> S3
    end
    subgraph BOUND["مفتاح مرور مربوط بالجهاز"]
        B1["مفتاح أمن (YubiKey ونحوه) /<br/>Windows Hello /<br/>Microsoft Authenticator (Entra ID)"]
        B2["المفتاح الخاصّ لا يخرج مادّيّاً<br/>من ذلك العتاد (يحميه TPM ونحوه)"]
        B3["المزيّة: موضع المفتاح واضح في مكان واحد<br/>انتبهوا: تسجيل متعدّد إلزاميّ للفقدان"]
        B1 --> B2 --> B3
    end
    SYNC ~~~ BOUND

الشكل 6: المتزامن والمربوط بالجهاز. كلاهما يشتركان في «عدم إرسال المفتاح الخاصّ إلى الخادم»، ومركز أسلوب الحماية يختلف

مفتاح المرور المتزامن هو ما تزامن فيه سلسلة مفاتيح iCloud أو مدير كلمات مرور Google المفتاح الخاصّ بين أجهزة الحساب نفسه. المهمّ هنا أنّ المزامنة مشفَّرة من طرف إلى طرف. تصرّح Apple وGoogle كلتاهما بأنّ مفاتيح المرور تُشفَّر على الجهاز ثمّ تُزامَن، وأنّ المشغّل نفسه لا يستطيع قراءة المحتوى.⁷⁸ أي أنّ مبدأ «المفتاح الخاصّ لا يغادر الجهاز» يُرخَّى بدقّة إلى «المفتاح الخاصّ لا يغادر الجهاز كنصّ صريح»، وفي المقابل تُكتسَب مقاومة لتغيير الجهاز والفقدان.

كيف يغيّر هذا الترخيص نموذج التهديد ينبغي التصريح به بوضوح. الموضع الذي يلزم الدفاع عنه يتجمّع من «خادم كلّ موقع» إلى «حساب سحابيّ واحد». تبقى القوّة أمام تسرّب قواعد بيانات المواقع والتصيّد كما هي، لكن الاستيلاء على Apple ID/حساب Google نفسه يصير نقطة فشل واحدة. لذلك، الحساب الذي تودعون فيه مفاتيح المرور يحتاج أقوى حماية (قفل شاشة قويّ، وترتيب وسائل الاسترداد، ومفتاح أمن مادّيّ إن أمكن) كشرط أساسيّ. أصدر NIST أيضاً في أبريل 2024 ملحقاً لـ NIST SP 800-63B (Supplement 1: Incorporating Syncable Authenticators Into NIST SP 800-63B)، ووضع رسميّاً أنّ مفتاح المرور المتزامن هذا (syncable authenticator) يستطيع، إن استوفى المتطلّبات، الوفاء بـ AAL2 (Authenticator Assurance Level 2، مستوى ضمان المصادِق 2) وفق المعيار الحكوميّ. غير أنّه، ما دام المفتاح الخاصّ قابلاً للتصدير، لا تُستخدم النوع المتزامن لـ AAL3 الذي يتطلّب بيئة معزولة بالعتاد.⁶

مفتاح المرور المربوط بالجهاز نوع لا يخرج فيه المفتاح الخاصّ من العتاد. مفاتيح الأمن مثل YubiKey نموذجيّة، وفي الاستخدام المؤسّسيّ مفاتيح مرور Microsoft Entra ID (التي تُنشأ داخل Microsoft Authenticator) مربوطة بالجهاز أيضاً.⁹ Windows Hello في Windows أيضاً، إن وُجد TPM، يحمي المفتاح الخاصّ تحت TPM. آليّة «خزنة العتاد التي لا تُخرج المفتاح» نفسها هي الأساس الذي شُرح تفصيلاً في مقال TPM.

كذلك، ربّما استغربتم أن يُطلب منكم قراءة رمز QR حين «تسجّلون الدخول بمتصفّح الحاسوب بمفتاح مرور الهاتف». ذلك ليس انتقال شاشة فحسب، بل طريقة هجينة (مصادقة عبر الأجهزة من FIDO) تؤكّد القرب المادّيّ بين الهاتف والحاسوب عبر Bluetooth. تُسقِط تأكيد القرب هجوماً يحاول فيه مهاجم بعيد جعل شخص آخر يوافق على تسجيل دخول إلى حاسوبه عبر رمز QR.¹

6. ليست رصاصة فضّيّة ── الضعف لا «يختفي» بل «ينتقل»

شرحنا قوّة مفاتيح المرور حتّى هنا، لكن بصدق، مفاتيح المرور لا تُفني الهجوم بل تدفع المهاجم إلى مواضع أضعف. حين يتصلّب باب المصادقة، نرسم إلى أين يلتفّ المهاجم.

flowchart LR
    A["المهاجم"]
    G["المصادقة نفسها<br/>توقيع التحدّي<br/>【صلب】"]
    R["تدفّق استرداد الحساب<br/>الإبلاغ بـ«فقدت مفتاح المرور»<br/>وإعادة الإعداد عبر SMS أو البريد،<br/>وتسجيل مفتاح مرور المهاجم"]
    F["احتياط متزامن الوجود<br/>إن بقي تسجيل دخول بكلمة مرور أو SMS<br/>فالحلقة الأضعف هناك"]
    C["الحساب السحابيّ<br/>إن كان متزامناً فـ Apple ID /<br/>حساب Google نقطة فشل واحدة"]
    SS["الجلسة<br/>سرقة ملفّ تعريف الارتباط بعد تسجيل الدخول<br/>تجعل طريقة المصادقة غير ذات صلة"]
    A --x G
    A --> R
    A --> F
    A --> C
    A --> SS

الشكل 7: حين يتصلّب الباب (المصادقة)، ينتقل الهجوم إلى تدفّق الاسترداد ووسائل الاحتياط والحساب السحابيّ والجلسة

مخاطر متبقّية أربعة ينبغي ضبطها عمليّاً.

1. الاحتياط المتزامن الوجود يصير الحلقة الأضعف. إن جعلتم مفاتيح المرور «أيضاً» قابلة للاستخدام فحسب، وبقيت كلمات المرور أو تسجيل الدخول بـ SMS، يستخدم المهاجم تلك فحسب. مقاومة التصيّد تُحدَّد، على مستوى الحساب كلّه، بمستوى أضعف وسيلة تسجيل دخول. جوهر النشر ليس إضافة مفاتيح المرور بل التقليص والإلغاء المخطَّط للاحتياط.
2. تدفّق الاسترداد يصير سطح هجوم جديداً. حيلة ادّعاء «فقدت الجهاز» ودفع إعادة الإعداد عبر مكتب الدعم أو البريد، لتسجيل مفتاح مرور المهاجم نفسه. في الواقع، الهندسة الاجتماعيّة لخداع مكتب المساعدة وتجاوز مصادقة قويّة صارت وسيلة معتادة لانتهاكات واسعة. بقدر ما تصلّبون المصادقة، يُسأل كيف تُصمَّم التحقّق من الهويّة في تدفّق الاسترداد.
3. في النوع المتزامن يصير الحساب السحابيّ نقطة فشل واحدة. كما في القسم السابق. يلزم دفاع الحساب الذي تودعون فيه مفاتيح المرور، ووضع سياسة «أيّ منصّة يُسمح بالمزامنة إليها» عند الاستخدام المنظّماتيّ.
4. سرقة الجلسة لا تُمنَع. ما تحميه مفاتيح المرور لحظة تسجيل الدخول فقط؛ إن سُرق ملفّ تعريف ارتباط الجلسة بعد تسجيل الدخول ببرمجيّة خبيثة أو XSS فطريقة المصادقة غير ذات صلة. يبقى عمل طبقة أخرى: مدّة صلاحية الرمز والربط وإدارة سلامة الجهاز.

هذه ليست قصّة «فلنترك مفاتيح المرور». قصّة بديهيّة أنّ تحديث قفل الباب عمل منفصل عن إقفال النوافذ. بل بقدر ما يتّضح موضع الضعف، يمكن تركيز موارد الدفاع على تدفّق الاسترداد وإدارة الجلسة.

7. النشر العمليّ ── واجهة WebAuthn وبيئة Windows

أخيراً، نضبط النقاط من منظور من ينشر.

إضافة تسجيل دخول بمفتاح مرور إلى خدمة ويب خاصّتكم

جانب المتصفّح دالّتان فقط من واجهة WebAuthn. التسجيل يستدعي navigator.credentials.create()، والمصادقة navigator.credentials.get().

// التسجيل (جانب المتصفّح)
const credential = await navigator.credentials.create({
  publicKey: {
    challenge: challengeFromServer,   // قيمة عشوائيّة لمرّة واحدة يولّدها الخادم
    rp: { id: "example.com", name: "Example" },
    user: { id: userIdBytes, name: "taro@example.com", displayName: "Taro" },
    pubKeyCredParams: [{ type: "public-key", alg: -7 }],  // ES256
    authenticatorSelection: {
      residentKey: "required",        // يجعلها بيانات اعتماد قابلة للاكتشاف (أي مفتاح مرور)
      userVerification: "required",   // يجعل التحقّق من الهويّة بالحيويّات أو PIN إلزاميّاً
    },
  },
});
// يُستخرج المفتاح العامّ من credential.response، وcredential ID
// من credential.id / credential.rawId في المستوى الأعلى. كما في
// المصادقة، تحقّقوا من التحدّي والأصل وRP ID في جانب الخادم
// قبل تخزين استجابة التسجيل.

معاني المعاملات الرئيسة كالتالي.

جدول 4: المعاملات الرئيسة لـ navigator.credentials.create()

ملاحظة بيئة التحقّق: لا تُكشَف واجهة WebAuthn إلا في سياق آمن، لذا تفشل استدعاءات navigator.credentials على صفحة تُسلَّم بـ http:// صِرف. الاستثناء http://localhost (و127.0.0.1)، فهذه تُعامَل أصولاً موثوقة، فيمكن على آلة التطوير التجريب دون تحويل إلى HTTPS. غير أنّ RP ID يجب أن يكون النطاق الفعّال للأصل (أو نطاقاً أباً له)، لذا مفتاح مرور صُنع على localhost لا يُستخدم على نطاق الإنتاج. حتّى بلا مصادِق في اليد، تفعيل مصادِق افتراضيّ في علامة تبويب «WebAuthn» في أدوات مطوّر Chrome يتيح تشغيل التسجيل فالمصادقة بالكامل.

// المصادقة (جانب المتصفّح)
const assertion = await navigator.credentials.get({
  publicKey: {
    challenge: challengeFromServer,
    rpId: "example.com",
    userVerification: "required",
  },
  // يعرض مفتاح المرور كاقتراح ملء تلقائيّ في حقل تسجيل الدخول.
  // تحقّقوا مسبقاً من الدعم بـ
  // PublicKeyCredential.isConditionalMediationAvailable()، وفي المتصفّحات
  // غير المدعومة عودوا إلى استدعاء عاديّ بلا mediation
  mediation: "conditional",
  // (يتطلّب autocomplete="username webauthn" على عنصر <input> المستهدف)
});
// تحقّقوا من التوقيع في assertion.response في جانب الخادم

الجوهر التحقّق في جانب الخادم. كحدّ أدنى، نفّذوا التالي حتماً.⁵

• مطابقة التحدّي: أهو تحدٍّ أصدرتموه ولم يُستخدم؟ هل جعلتموه لمرّة واحدة (مكافحة إعادة التشغيل)؟ علاوة على ذلك، احفظوه مربوطاً بجلسة المتصفّح عند الإصدار (محاولة تسجيل الدخول)، ولا تسمحوا بالاستهلاك إلا لاستجابة من الجلسة نفسها. إن تراخى هذا، يتّسع مجال أن يُرسل مهاجم توقيعاً على تحدٍّ موجَّه إليه عبر متصفّح الضحيّة، فيُسجَّل دخول الضحيّة إلى حساب المهاجم (CSRF لتسجيل الدخول).
• مطابقة الأصل: هل origin في clientDataJSON هو الأصل الشرعيّ لموقعكم (جوهر مكافحة التصيّد).
• مطابقة تجزئة RP ID: هل rpIdHash في authenticatorData يطابق SHA-256 لـ RP ID لموقعكم.
• تأكيد نوع المراسم والأعلام: هل type في clientDataJSON هو webauthn.get للمصادقة وwebauthn.create للتسجيل. هل علم UP (حضور المستخدم) في authenticatorData مرفوع. إن طلبتم تحقّق المستخدم (UV)، هل علم UV مرفوع أيضاً.
• التحقّق من التوقيع: هل يتحقّق التوقيع صحيحاً بالمفتاح العامّ المحفوظ عند التسجيل.
• الربط بالحساب: هل تسحبون credential ID المقدَّم (وuserHandle) من قاعدة بياناتكم، وتُصدرون الجلسة لمالك بيانات الاعتماد تلك. الوثوق باسم مستخدم أُدخل على حدة دون شرط يصير ثغرة تسجّل الدخول كشخص آخر بتوقيع صحيح.
• حفظ عدّاد التوقيع ومقارنته: احفظوا signCount في authenticatorData لكلّ بيانات اعتماد، وأكّدوا أنّ القيمة التالية أكبر من السابقة. إن كانت أقلّ من السابقة أو مساوية فعاملوها علامة استنساخ للمصادِق. غير أنّ مفاتيح المرور المتزامنة كثيراً ما تُعيد 0 دائماً، لذا اسمحوا باستثناء 0 مقابل 0 فقط.

كتابة هذا التحقّق يدوياً مصدر حوادث، فاستخدموا مكتبة ذات سجلّ (.NET: fido2-net-lib، وNode.js: SimpleWebAuthn ونحوهما). تفاصيل المواصفة (تحليل CBOR، واتّفاق الخوارزميّة، وإدارة التحدّي) اتركوها للمكتبة، وركّزوا أنتم على حفظ التحدّي وإبطاله، وواجهة إدارة عدّة مفاتيح مرور، وتصميم تدفّق الاسترداد — هذا التوزيع الصحيح للجهد.

بيئة Windows والأنظمة الداخليّة

من موقف قرّاء هذا الموقع «من يتولّون أنظمة أعمال Windows»، تكفي النقاط الثلاث التالية.

• عميل Windows مدعوم أصلاً. يدعم Windows 11 إنشاء مفاتيح المرور واستخدامها وإدارتها (الإعدادات > الحسابات > مفاتيح المرور) باتّخاذ Windows Hello مصادِقاً، ويُحمى المفتاح الخاصّ بالعتاد إن وُجد TPM.¹⁰ WebAuthn عبر المتصفّح (Edge/Chrome) يعمل أيضاً على Windows 10.
• في بيئة Entra ID فعّلوا «مفتاح المرور = طريقة مصادقة FIDO2». يدعم Microsoft Entra ID مفاتيح الأمن ومفاتيح المرور داخل تطبيق Microsoft Authenticator (مربوطة بالجهاز)، وإن طلبتم «MFA مقاوم للتصيّد» بقوّة المصادقة في الوصول المشروط يمكن قصر الوصول إلى المورد المستهدف على مفاتيح المرور ونحوها.⁹ الانتقال من عالم NTLM وسياسات أجل كلمة المرور لا يجري قفزة واحدة، لذا الممارسة القياسيّة إلزام MFA المقاوم للتصيّد أوّلاً على حسابات المديرين، بالتوازي مع جرد بنية المصادقة الذي عالجه مقال NTLM وKerberos.
• في تطبيقات الويب الداخليّة الفائدة نفسها. غير أنّ HTTPS مفترض. لا تعمل واجهة WebAuthn إلا في سياق آمن، لذا حتّى في تطبيقات الإنترانت (باستثناء localhost عند التطوير) يأتي أوّلاً التحويل إلى HTTPS وترتيب اسم نطاق داخليّ يصلح RP ID. متى تمّ ذلك يعمل RP ID تجاه النطاق الداخليّ أيضاً. بمعنى القطيعة مع كلمة المرور الملصقة بورقة، ليس نادراً أن يظهر الأثر في الداخل أسرع ممّا في الخدمات الخارجيّة.

8. الخلاصة

• ضعف كلمة المرور ليس القوّة بل بنية «الاشتراك في سرّ وإرساله في كلّ مصادقة». يوجد السرّ لدى المستخدم وحقل الإدخال والمسار والخادم جميعاً، فتكثر أهداف الهجوم. إضافة رمز لمرّة واحدة تُهزَم أيضاً بترحيل تصيّد AiTM.
• مفتاح المرور زوج مفاتيح تشفير بالمفتاح العامّ لكلّ موقع، يسلّم الخادم المفتاح العامّ الآمن إن تسرّب فقط، ويرسل عند تسجيل الدخول توقيعاً على تحدٍّ لمرّة واحدة فقط. لا سرّ على الخادم، ولا سرّ يسير على المسار.
• يُخبَز في التوقيع الأصل وRP ID اللذان أكّدهما المتصفّح، لذا لا يظهر مفتاح المرور الحقيقيّ مرشَّحاً على موقع مزيّف، وحتّى الترحيل يسقط في التحقّق. أنّ المستخدم لا يحتاج إلى اكتشاف الموقع المزيّف هو جوهر «مقاومة التصيّد»، وقد انتقل أساس الدفاع من يقظة الإنسان إلى بنية البروتوكول.
• مفاتيح المرور المتزامنة تُزامَن بـ تشفير من طرف إلى طرف وهي قويّة أمام تغيير الجهاز والفقدان. في المقابل يتجمّع الموضع الذي يلزم الدفاع عنه في الحساب السحابيّ، فيصير دفاع Apple ID/حساب Google نفسه شرطاً أساسيّاً. تستطيع المؤسّسات أيضاً اختيار المربوط بالجهاز (مفاتيح الأمن، ومفاتيح مرور Authenticator في Entra ID).
• مفاتيح المرور لا تُفني الهجوم بل تدفعه إلى مواضع أضعف. كلمات المرور المتزامنة الوجود، وتدفّق استرداد الحساب، وسرقة الجلسة تبقى سطوح هجوم، وجوهر النشر التقليص المخطَّط للاحتياط وتحصين تدفّق الاسترداد.
• التنفيذ دالّتا create / get في واجهة WebAuthn زائد التحقّق في الخادم. لا تبنوا التحقّق بأنفسكم واتركوه لمكتبة ذات سجلّ، وخصّصوا الجهد لإدارة التحدّي وواجهة عدّة مفاتيح مرور وتصميم الاسترداد.

مقالات ذات صلة

• ما هو TPM في Windows؟ ── دليل مُصوَّر لـ«الخزنة التي لا تُخرج المفاتيح» والإقلاع المقيس
• NTLM وKerberos مشروحان بالرسوم ── لماذا تسقط المصادقة إلى NTLM
• دمج مصادقة Entra ID في تطبيقات WinForms/WPF ── التشكيل العمليّ لـ MSAL.NET ووسيط WAM
• التعامل الآمن مع الاعتمادات في PowerShell ── طرد كلمات المرور الصريحة من السكربتات
• قائمة تحقّق للحدّ الأدنى من الأمان في تطوير تطبيقات Windows
• من أين تبدأ الشركات الصغيرة والمتوسّطة في تدابير الأمان؟ ── كيفيّة قراءة الإصدار 4.0 من «الدليل الإرشادي لتدابير أمن المعلومات للشركات الصغيرة والمتوسّطة» الصادر عن IPA

مجالات الاستشارة ذات الصلة

تتعامل شركة كومورا سوفت ذ.م.م. مع Custom Software Development يشمل دعم تنفيذ تسجيل الدخول بمفتاح المرور / WebAuthn في أنظمة الويب الداخليّة، وتصميم نشر MFA المقاوم للتصيّد في بيئة Entra ID، ودمج المصادقة في تطبيقات أعمال Windows مثل WinForms/WPF.

روابط مرجعيّة

مقالات ذات صلة

أحدث المقالات التي تشترك في نفس الوسوم. عمّق فهمك بمواضيع مرتبطة.

الأسئلة الشائعة

أسئلة شائعة حول موضوع هذه المقالة.

ما الفرق الجوهريّ بين مفاتيح المرور وكلمات المرور؟

كلمة المرور آليّة يشترك فيها المستخدم والخادم في السرّ نفسه ويرسلان ذلك السرّ في كلّ تسجيل دخول. لأنّ السرّ يوجد في كلّ مكان — في رأس المستخدم، وفي حقل الإدخال، وعلى الخطّ، وفي قاعدة بيانات الخادم — يصير كلّ موضع منها هدفاً للهجوم. مفتاح المرور يستخدم زوج مفاتيح من التشفير بالمفتاح العامّ، ولا يُرسل المفتاح الخاصّ إلى الخادم قطّ. مع مفتاح مرور مربوط بالجهاز، لا يغادر المفتاح الخاصّ المصادِق أصلاً؛ وحتّى مع مفتاح مرور متزامن لا يغادر الجهاز إلا بشكل مشفَّر من طرف إلى طرف. كلّ ما يخزّنه الخادم هو المفتاح العامّ — معلومات آمنة إن تسرّبت — وكلّ ما يُرسل عند تسجيل الدخول توقيع على تحدٍّ لمرّة واحدة. بعبارة أخرى، السرّ المشترك الذي كان ضعف كلمة المرور الجوهريّ لا يوجد أصلاً. فوق ذلك، لأنّ زوج المفاتيح يُنشأ لكلّ موقع على حدة، لا ينطبق مفهوم إعادة الاستخدام أصلاً.

هل تُرسل البيانات الحيويّة (بصمة الإصبع، الوجه) إلى الخادم؟

لا. بيانات البصمة أو الوجه تُستخدم فقط للمطابقة المحلّيّة داخل الجهاز — لفتح باب الخزنة التي تحمل المفتاح الخاصّ — وبتصميم FIDO لا تُنقَل البيانات الحيويّة خارج الجهاز قطّ. كلّ ما يتلقّاه الخادم توقيع مع رفع العلم بأنّ التحقّق من الهويّة (تحقّق المستخدم) جرى؛ لا يحتوي شيئاً من البصمة نفسها، ولا حتّى أيّ متّجه سمات حيويّة مشتقّ منها. حيث يتعذّر استخدام الحيويّات، يمكن أن يحلّ PIN محلّها، ومثل PIN في Windows Hello يُطابَق هذا PIN أيضاً محلّيّاً على الجهاز فقط — الفرق الحاسم عن كلمة المرور أنّه لا يسير على الشبكة قطّ.

لماذا تقاوم مفاتيح المرور التصيّد؟

لأنّه، بالتصميم، لا يحتاج المستخدم إلى اكتشاف موقع مزيّف أصلاً. يُنشأ مفتاح المرور مربوطاً بنطاق الموقع (معرّف الطرف المعتمد، RP ID)، ولا يعرض المتصفّح إلا مفاتيح المرور المطابقة لنطاق الموقع المعروض حالياً. حتّى إن زرتم نطاقاً مزيّفاً يبدو مطابقاً للحقيقيّ، لا يظهر مفتاح المرور للموقع الحقيقيّ كخيار، فلا سبيل لخداع المستخدم. فوق ذلك، يُخبَز في التوقيع الأصل الذي أكّده المتصفّح وتجزئة RP ID، لذا حتّى لو أُعيد ترحيل التوقيع، يرفضه التحقّق على الخادم الحقيقيّ. الاستحالة البنيويّة للحادث الذي يبتلي كلمات المرور ورموز SMS — إدخال بيانات اعتماد حقيقيّة في موقع مزيّف — هي الفرق الجوهريّ عن التدابير التي تعتمد على التدريب واليقظة.

إن فقدت هاتفي، هل أُقفَل خارج حساباتي؟

إن كان مفتاح مرور متزامناً — مخزَّناً في سلسلة مفاتيح iCloud أو مدير كلمات مرور Google — يمكن استعادته إلى جهاز جديد مسجَّل الدخول إلى Apple ID أو حساب Google نفسه. غير أنّ استعادة الخزنة المشفَّرة من طرف إلى طرف تتطلّب لا كلمة مرور الحساب فحسب بل تحقّقاً إضافيّاً من الهويّة، مثل إدخال قفل شاشة الجهاز السابق (رمز المرور)، لذا إن فقدتم أيضاً وسائل الاسترداد تلك قد تتعذّر الاستعادة. يهمّ ألّا تودعوا كلّ شيء في هاتف واحد. مفاتيح المرور المربوطة بالجهاز (مفاتيح الأمن، Windows Hello ونحوها) تشارك مصير الجهاز، لذا الممارسة القياسيّة للحسابات المهمّة تسجيل أكثر من مفتاح مرور. معظم الخدمات تتيح تسجيل عدّة مفاتيح مرور على حساب واحد. لاحظوا أنّ كيفيّة إبطال مفتاح مرور مفقود تختلف حسب النوع. لمفتاح مرور متزامن، لأنّ النسخ على كلّ جهاز هي بيانات الاعتماد الواحدة نفسها، احذفوا أوّلاً الجهاز المفقود أو نفّذوا مسحاً عن بُعد من جانب حساب المنصّة لتعطيل النسخة على ذلك الجهاز (حذف مفتاح المرور في إعدادات حساب الخدمة نفسها يبطل النسخ على كلّ الأجهزة دفعة واحدة). لمفتاح مرور مربوط بالجهاز، حذف مفتاح مرور ذلك المصادِق من جانب الخدمة يبطل المفتاح المفقود فقط. للاستخدام المنظّماتيّ، يهمّ تصميم «ازدواجيّة حتّى يستطيع المستخدمون التعافي بأنفسهم» و«إجراء ليبطله المديرون عند الفقدان» معاً.

هل لمفتاح المرور نقاط ضعف أيضاً؟

نعم. وإن كان الأدقّ القول إنّ موضع الضعف ينتقل. لأنّ المصادقة نفسها تُصلَّب بالتشفير بالمفتاح العامّ، يصوّب المهاجمون إلى المناطق المحيطة الأضعف بدلاً من ذلك. تحديداً: إن بقيت طرائق قديمة مثل كلمات المرور أو SMS متزامنة الوجود، تبقى الحلقة الأضعف؛ وهناك حيلة إساءة استخدام تدفّق استرداد الحساب لتسجيل مفتاح مرور المهاجم نفسه؛ ولمفاتيح المرور المتزامنة، يصبح الاستيلاء على الحساب السحابيّ نفسه نقطة فشل واحدة جديدة. كذلك هجوم يسرق ملفّ تعريف ارتباط الجلسة بعد تسجيل الدخول لا توقفه مفاتيح المرور، لذا لا تختفي التهديدات غير ذات الصلة أيضاً. يحتاج النشر إلى تغطية لا «إضافة مفاتيح المرور» فحسب بل أيضاً تحصين تدفّق الاسترداد وتقليص مخطَّط لوسائل الاحتياط.

الملف الشخصي للمؤلف

صفحة الملف الشخصي لمؤلف المقالة.

غو كومورا

مؤسّس شركة كومورا سوفت ذ.م.م.

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