Pass-ta-key: ما الذي يعنيه الهجوم على مفاتيح مرور Google فعلاً

هل أصبحت مفاتيح المرور غير آمنة بعد كل شيء؟ هذا هو السؤال الذي يطرحه Pass-ta-key.

تصف وحدة Unit 42 التابعة لـ Palo Alto Networks ثلاث سلاسل هجوم تستطيع من خلالها برمجية خبيثة إساءة استخدام مفاتيح مرور Google المتزامنة، وتجاوز التحقق من المستخدم، وفي أخطر السيناريوهات استخراج جميع المفاتيح الخاصة لمفاتيح المرور في الحساب.

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

لكن اعتبار أن «كل شيء ضاع أصلاً على Endpoint مخترق» تحليل مريح أكثر من اللازم. يفترض أن يحول Golden Pass-ta-key اختراقاً محلياً إلى حزمة دائمة وقابلة للتصدير تضم كل مفاتيح المرور المتزامنة. وبذلك يتجاوز أثره سرقة جلسة متصفح واحدة.

الخلاصة المختصرة أولاً

نعم، هذا موضوع أمني جديد ومستقل. لكنه ليس سبباً لإلغاء مفاتيح المرور أو العودة إلى الاعتماد الحصري على كلمات المرور.

التقييم الصحيح هو:

• البروتوكول صامد: لم يُكسر Origin Binding أو Challenge-Response أو التشفير غير المتماثل.
• الهجوم يستهدف تنفيذاً محدداً: النطاق المثبت هو Google Password Manager مع Chrome وWindows وTPM كما اختبرته Unit 42.
• يجب أن يكون Endpoint مخترقاً مسبقاً: لا تستطيع أي صفحة عشوائية على الإنترنت تنفيذ الهجوم على حاسوب سليم.
• الضرر المحتمل كبير مع ذلك: تتدرج المتغيرات من إنشاء Login Assertion بصمت إلى استخراج المفاتيح الخاصة لكل مفاتيح المرور المتزامنة.
• للمفاتيح المتزامنة والمرتبطة بجهاز ملفات مخاطر مختلفة: كلاهما Passkeys، لكنهما لا يقدمان مستوى الأمان نفسه.
• تبقى كلمات المرور البديل الأضعف: يمكن تصيدها وإعادة استخدامها وتخمينها وسرقتها من قواعد بيانات الخوادم.

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

النطاق التقني وقوة الأدلة

تشمل الحقائق المثبتة حتى 31 أغسطس 2026 مسارات الهجوم التي وثقتها Unit 42، ومواصفة WebAuthn، ووثائق Google لمفاتيح المرور، ومشكلة Chromium الظاهرة علناً، ومتطلبات NIST الحالية للمصادقات القابلة للمزامنة. ويضاف إليها Pass-the-Passkey من SpecterOps، والثغرة CVE-2026-34348، وخفض FIDO الذي عرضته Proofpoint، والنتائج التقنية لدى Expel وSquareX.

نُشر البحث في 3 أغسطس وحُدثته Unit 42 في 14 أغسطس. وهو يخص صراحة Google Password Manager داخل Chrome على Windows في أجهزة تحتوي على Trusted Platform Module. قد تواجه المتصفحات وأنظمة التشغيل ومزودو Passkey الآخرون أسئلة معمارية مشابهة، لكن هذه الهجمات الثلاث لم تثبت ضدهم.

لا توجد حملة هجومية نشطة موثقة في الواقع تستخدم هذه التقنيات بعينها. الأدلة الحالية أبحاث وProofs of Concept وResponsible Disclosure. وهذه نقطة أساسية في تقدير المخاطر: النجاح التقني في المختبر لا يعني استغلالاً واسعاً بالفعل.

ما الذي يحميه Passkey فعلاً؟

Passkey ليس كلمة مرور طويلة جداً، بل اعتماد WebAuthn مبني على التشفير غير المتماثل.

عند التسجيل ينشئ Authenticator زوج مفاتيح:

private key -> remains with the authenticator
public key  -> is registered with the online service

تخزن الخدمة، وتسمى في WebAuthn ‏«Relying Party»، المفتاح العام مع Credential-ID وحساب المستخدم. وعند الدخول ترسل Challenge جديدة وعشوائية. يوقع Authenticator بيانات تربط، ضمن أشياء أخرى، هذه Challenge بسياق الموقع الذي استدعى العملية. ثم يتحقق الخادم من التوقيع بالمفتاح العام المخزن.

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

كما أن الارتباط بـ Relying-Party-ID وWeb-Origin حاسم. مفتاح مرور خاص بـ example.com لا ينتج على نطاق تصيد مشابه Assertion صالحة لـ example.com. ولا يوجد سر يمكن للمستخدم إدخاله في الموقع الخطأ أو إملاؤه لمهاجم عبر الهاتف.

هذا هو معنى مقاوم للتصيد. يعرّف NIST المصطلح بدقة: يجب ألا يحصل Verifier احتيالي على سر المصادقة ولا على استجابة قابلة للاستخدام لدى الخدمة الحقيقية. ويحقق WebAuthn ذلك بالربط التشفيري باسم Verifier.

تظل هذه الخاصية سليمة في Pass-ta-key. البرمجية الخبيثة لا تبني صفحة تصيد أفضل، بل تعمل مسبقاً على الجهاز الذي يعامله المستخدم بوصفه Authenticator موثوقاً.

User Presence ليس User Verification

لفهم الهجمات الثلاث يجب التمييز بين إشارتين في WebAuthn:

• User Presence, UP: نفذ المستخدم فعل حضور، مثل لمس Security Key أو تأكيد مربع حوار.
• User Verification, UV: تحقق Authenticator من المستخدم محلياً، مثلاً عبر Windows Hello أو PIN أو القياسات الحيوية.

تحمل WebAuthn Assertion النتيجتين كعلامات داخل authenticatorData. ولا يجوز للخادم أن يثق فقط بما طلبه عند بدء الدخول. فإذا طلب userVerification: "required" وجب عليه التأكد أيضاً من ضبط علامة UV في الاستجابة.

هذه النقطة الواحدة مهمة. لم تستطع Unit 42 إكمال هجوم Pass-ta-key البسيط على GitHub لغياب User Verification المطلوب. أما eBay فقبل الدخول أولاً رغم أنه طلب User Verification، ثم أصلح التحقق من جهة الخادم بعد الإبلاغ.

يوضح الفرق أن التوقيع الصحيح تشفيرياً لا يكفي دائماً لمصادقة متعددة العوامل مطبقة بصورة صحيحة. يجب أن تتحقق Relying Party أيضاً من شروط الأمان التي أكدها Authenticator فعلاً.

لماذا تنشئ مفاتيح المرور المتزامنة نطاق ثقة إضافياً؟

يبقى Passkey المرتبط بجهاز داخل Authenticator محدد، مثل Hardware Security Key أو Platform Authenticator محمي محلياً. أما Passkey المتزامن فيجب أن يتوفر على عدة أجهزة. ولذلك ينبغي حفظ مادته الخاصة مشفرة، ونقلها عبر بنية مزامنة، واستعادتها على أجهزة أخرى مصرح بها.

هذا ليس فرقاً تنفيذياً صغيراً. فالمزامنة توسع المنظومة:

Relying Party
    |
browser and WebAuthn client
    |
local platform authenticator
    |
passkey manager and recovery logic
    |
cloud sync and additional devices

تحتاج كل طبقة إضافية إلى قواعدها الخاصة لثقة الأجهزة وOnboarding وRecovery وتشفير المفاتيح والإلغاء.

لذلك يعامل NIST المصادقات القابلة للمزامنة كفئة مستقلة. يمكن أن تناسب سيناريوهات حتى Authentication Assurance Level 2. أما AAL3 فيتطلب مفاتيح غير قابلة للتصدير داخل بيئة محمية عتادياً أو Authenticator منفصل. لا يعني ذلك أن Passkeys المتزامنة ضعيفة، بل إن الراحة وقابلية نقل المفتاح تنتجان نموذج Assurance مختلفاً.

ويستهدف Pass-ta-key هذا النطاق الإضافي من الثقة تحديداً.

النطاق الدقيق للبحث

تذكر Unit 42 عدة شروط غابت عن كثير من العناوين:

• يدير Google Password Manager مفاتيح المرور المتزامنة المتأثرة.
• يعمل Chrome على Windows.
• يحتوي الجهاز على TPM.
• تعمل البرمجية الخبيثة مسبقاً في سياق مستخدم الضحية.
• أُعد المستخدم داخل بيئة Chrome وGoogle ذات الصلة.
• في بعض المتغيرات يجب أن تقرأ البرمجية بيانات Chrome المحلية أو تعدل ملفات الحالة أو تفحص ذاكرة عملية Chrome.

لم يُثبت هجوم شامل على كل Passkey. ولم يُثبت أن مهاجماً بعيداً يستطيع، من دون اختراق Endpoint مسبق، سحب مفتاح WebAuthn ببساطة من TPM.

لذلك فإن عبارة «كُسرت Passkeys» خاطئة. والوصف الدقيق هو: عرضت Unit 42 ثلاث سلاسل هجوم على آليات الثقة وOnboarding وRecovery لمفاتيح Google المتزامنة على Windows Endpoints مخترقة.

المرحلة صفر: خريطة Passkeys المحلية

قبل أي من المتغيرات الثلاثة تقرأ البرمجية، وفق Unit 42، قاعدة Chrome Sync المحلية. توجد فيها سجلات WebauthnCredentialSpecifics التي تتضمن معلومات Relying Party وأسماء المستخدمين وCredential-IDs ومادة المفتاح الخاص المشفرة.

المسار المذكور في البحث هو:

%LocalAppData%\Google\Chrome\User Data\<Profile>\Sync Data\LevelDB

لم يحتج الوصول إلى هذه السجلات في الاختبار إلى صلاحيات مرتفعة. ورغم أن مادة المفتاح الخاص ليست نصاً واضحاً، تمنح Metadata البرمجية قائمة أهداف: لأي خدمات توجد Passkeys، ولأي حسابات، وأي Credential-ID يجب استهدافها؟

وهذا مهم بالفعل للكشف. لا يحتاج Infostealer إلى تخمين الأهداف، بل يستطيع جردها أولاً ثم مهاجمة الحسابات عالية القيمة انتقائياً.

Pass-ta-key: Assertion صالحة بلا فعل من المستخدم

يسيء المتغير الأول استخدام مفتاح الجهاز الذي يثبت به Chrome هوية جهاز Windows أمام Google Cloud Authenticator.

ينشئ Chrome لهذا الغرض Identity Key مدعوماً بـ TPM. وتوضح Unit 42 أن Chrome لا يخزن المفتاح الخاص كمفتاح نصي عادي، بل يصدره عبر Windows CNG على هيئة NCRYPT_OPAQUE_KEY_BLOB. يحمي TPM هذا Blob بحيث يمكن استيراده للعمليات التشفيرية مجدداً على TPM المادي نفسه.

هذا سليم تشفيرياً، لكنه لا يحل مشكلة التفويض تلقائياً. وفق البحث استطاعت برمجية في سياق المستخدم العادي قراءة wrapped_identity_private_key المخزن أو استخراجه من ذاكرة Chrome، ثم استدعاء وظائف Windows CNG المعتادة. ينفذ TPM التوقيع لأن الطلب يأتي تقنياً من الجهاز الصحيح، لكنه لا يعرف هل استدعى API برنامج Chrome أم البرمجية الخبيثة.

المسار المبسط هو:

attacker requests a fresh challenge from the online service
    -> malware on the victim PC uses the TPM-bound identity key
    -> Google Cloud Authenticator accepts the device identity
    -> Cloud Authenticator creates a valid passkey assertion
    -> attacker submits the assertion to the online service

لا يلزم تصدير ملف المفتاح الخاص في هذا المتغير. تستخدم البرمجية الجهاز المخترق وGoogle Cloud Authenticator كخدمة توقيع.

القيد الطبيعي هو علامة UV. يثبت Identity Key حيازة الجهاز، لا نجاح PIN أو القياسات الحيوية. والخدمة الصحيحة التي تفرض User Verification وتتحقق من نتيجته يجب أن ترفض Assertion ذات UV = 0.

لكن هذا لا يجعل المتغير بلا خطر. تضبط خدمات كثيرة User Verification على preferred لأسباب توافق أو UX، وأخرى تطلبه لكن تتحقق من الاستجابة بصورة خاطئة. عندئذ يتحول دخول مصمم كمتعدد العوامل عملياً إلى عامل واحد: الوصول إلى هوية الجهاز.

Silver Pass-ta-key: تسجيل هوية UV يملكها المهاجم

يتجاوز Silver Pass-ta-key القيد السابق. لا يحاول المهاجم كسر Windows Hello أو بيانات الضحية الحيوية، بل يجعل Cloud Authenticator يقبل مستقبلاً مفتاحاً يملكه المهاجم كإثبات صالح لـ User Verification.

نقطة البداية هي Re-Onboarding. تستطيع البرمجية، وفق البحث، جعل Cloud Authenticator ينسى حالة الجهاز القائمة أو حذف الملف المحلي passkey_enclave_state. وعند عملية Passkey التالية يجب على Chrome تسجيل الجهاز من جديد.

في Windows لا يُنشأ User-Verification-Key بالضرورة في أول خطوة. يمكن أن يستخدم Chrome أولاً Google-Password-Manager-Recovery-PIN ويضبط الحالة uv_key_pending. ثم يُنشأ UV-Key الفعلي عند استخدام Passkey التالي. وهذه الحالة الوسيطة المصممة للراحة تفتح نافذة الهجوم.

للتحضير يجب أن يمر الضحية بخطوة Recovery أو Re-Onboarding التي شغلت بصورة غير متوقعة، وأن يدخل GPM-PIN. ولا تحتاج البرمجية إلى سرقة PIN، بل تستغل حالة uv_key_pending الناتجة. بعدها يمكن إجراء عمليات دخول مسيئة من دون تفاعل إضافي ومن دون اتصال جهاز الضحية.

ينشئ المهاجم زوج مفاتيح في بيئته ويرسل المفتاح العام كـ UV-Key جديد. وفق نتائج Unit 42 لم يتحقق Google Cloud Authenticator من أن المفتاح الجديد صدر فعلاً من عتاد موثوق. وخزن النظام مفتاح المهاجم إلى جانب هوية الجهاز الشرعية.

من تلك اللحظة يستطيع المهاجم توقيع الطلبات بمفتاحه الخاص. يعاملها Cloud Authenticator كأن User Verification حدث محلياً وينشئ Assertions بعلامة UV مضبوطة. ولا يلزم أن يبقى جهاز الضحية متصلاً لعمليات الدخول اللاحقة.

تصف مشكلة Chromium العامة السلوك بعنوان «GPM Passkeys Are Vulnerable to User Verification Key Abuse». وكانت موسومة WAI وقت المراجعة. وبصرف النظر عن التقييم الداخلي، توضح الحالة قاعدة معمارية مهمة: عملية Recovery أو Onboarding التي تربط مفتاحاً موثوقاً جديداً هي نفسها عملية مصادقة شديدة الحساسية.

Golden Pass-ta-key: تحويل Cloud Sync إلى مادة مفاتيح قابلة للتصدير

Golden Pass-ta-key هو المتغير الأخطر. يستهدف Security Domain Secret أو SDS، وهو سر بطول 32 Byte يحمي المفاتيح الخاصة المتزامنة لحساب Google Password Manager.

الوعد المعماري المبسط أن Client لا يملك سوى wrapped_secret مشفر. ويحدث فك التشفير في Cloud Authenticator بمفتاح خاص بالجهاز، فلا يفترض أن تصل برمجية على Client بسهولة إلى مفاتيح Passkey الخاصة.

لكن بنية Sync تحتاج أثناء Onboarding وRecovery إلى إعادة إدخال الأجهزة في Security Domain. وجدت Unit 42 أن Chrome يتلقى SDS حينها في صورة يمكن للـ Client الوصول إليها. ظهر أولاً حتى في FIDO Diagnostic Log في Chrome، ثم أزالت Google ذلك بعد الإبلاغ. ومع ذلك يمر SDS أثناء العملية عبر ذاكرة Chrome.

لذلك لا يمثل Golden Pass-ta-key سحباً عشوائياً للذاكرة في أي وقت. تبدأ البرمجية بإجبار مسار Onboarding أو Recovery الحساس، ثم يجب أن تصيب اللحظة التي يوجد فيها SDS داخل عملية Chrome. يزيد هذا صعوبة الهجوم، لكنه لا يغير نطاق السر بعد استخراجه بنجاح.

تجمع السلسلة عدة خطوات:

1. تفرض البرمجية Onboarding جديداً.
2. تنتظر إنشاء أو تغيير حالة Enclave المحلية.
3. تقرأ ذاكرة Chrome في اللحظة المناسبة وتبحث عن SDS.
4. تربط SDS بسجلات Sync التي قرأتها سابقاً.
5. تفك تشفير المفاتيح الخاصة لمفاتيح المرور داخلها.
6. يستطيع Authenticator مستقل عن جهاز الضحية إنشاء Assertions صالحة بعد ذلك.

هنا يكمن الفرق النوعي عن Session-Cookie مسروق. يمكن أن تنتهي الجلسة أو يلغيها الخادم. أما Golden Pass-ta-key فيفترض أن يصدر المفاتيح الخاصة لكل Passkeys المتزامنة. وتذكر Unit 42 أيضاً أن SDS نفسه يحمي مفاتيح متزامنة تُنشأ مستقبلاً، وأن البنية المختبرة لم تعرض وسيلة واضحة لتدوير SDS أو إلغائه.

يصف ذلك حالة تنفيذ Google الذي دُرس، ولا يثبت أن كل مزود Passkey يستخدم Master-Key مماثلاً أو أن Google لن تغير المعمارية لاحقاً.

لماذا لا تجعل البرمجية المحلية الهجوم تافهاً؟

من يستطيع تشغيل برمجية عشوائية في سياق مستخدم حاسوب مسجل دخوله يملك طرقاً أسهل كثيرة: سرقة Session-Cookies، وقراءة محتوى المتصفح، وتعديل المعاملات، وتسريب الملفات، أو التصرف باسم المستخدم داخل حساب مفتوح. لا يمكن لأي مصادقة أن تثق بلا حدود في Client مخترق بالكامل.

وفئة الهجوم الأساسية ليست جديدة. سرقة أسرار أو Sessions نشطة من Password Manager ومتصفح مخترق جزء من أدوات Infostealers منذ سنوات. ولا يحول Pass-ta-key اختراق Endpoint قائم إلى هجوم بعيد سحري.

لكن رفضه على أنه تافه يختصر الصورة أكثر من اللازم. فقد قدم البحث نتائج تنفيذية محددة لم تكن بديهية:

• استطاعت عملية غير مميزة استخدام مفتاح جهاز Chrome المرتبط بـ TPM للتوقيع.
• اعتمد الحد بين حيازة الجهاز وUser Verification لدى Relying Parties على فحص علامة UV بصورة صحيحة.
• أتاحت حالة Re-Onboarding تسجيل UV-Key يسيطر عليه المهاجم.
• ظهر سر Sync المركزي أولاً في السجل، ثم ظل وفق البحث قابلاً للوصول في ذاكرة العملية.
• جعل أخطر مسار المفاتيح الخاصة المتزامنة قابلة لإعادة الاستخدام خارج الجهاز الأصلي.
• غالباً لا تملك Passkeys المتزامنة Signature Counter تقليدياً يصلح كإشارة موثوقة للاستنساخ، لأن أجهزة شرعية متعددة تستخدم Credential نفسه.

«Endpoint مخترق» شرط مسبق لا وصف كامل للأثر. ففي Incident Response هناك فرق كبير بين سرقة Session مؤقتة وبين امتلاك مادة مفاتيح خاصة طويلة الأجل لعدة خدمات.

Pass-ta-key ليس سوى جزء من سطح الهجوم الجديد

لم يظهر Pass-ta-key منفرداً. توضح أبحاث 2025 و2026 عدة طرق يستطيع بها المهاجم تقليل حماية Passkey من دون كسر مفتاحه الخاص رياضياً.

يتطلب سوء استخدام Sync وRecovery في Pass-ta-key برمجية تعمل بالفعل على Windows Endpoint. أما Pass-the-Passkey فيجمع الوصول إلى Assertion مسجلة مع ثغرة Replay لدى الخادم. وفي FIDO Downgrade يكفي وجود طريقة دخول إضافية قابلة للتصيد، بينما يتطلب Passkeys Pwned إضافة متصفح خبيثة أو تنفيذ Script في سياق المتصفح. ولا تهاجم Infostealers الـ Passkey نفسه، بل تسرق الجلسة الموثقة من متصفح أو Endpoint مخترق.

لا يكسر أي من هذه المسارات Public-Key-Kryptografie. وكلها تستهدف طبقة ثقة حول WebAuthn: Sync وRecovery، أو فحص الخادم، أو المتصفح، أو الجلسة بعد الدخول.

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

Pass-the-Passkey: حين تصبح Assertion صالحة قابلة لإعادة الاستخدام

حدد SpecterOps في Black Hat USA 2026 ثلاث ثغرات في Windows 11 وMicrosoft Entra ID وأكثر من 20 تقنية هجومية مشتقة. بدأت السلسلة الأهم من موضع غير متوقع: سجل Windows ‏WebAuthn Assertions كاملة في Event Log ‏Microsoft-Windows-WebAuthN/Operational.

تحتوي Assertion كهذه على Credential-ID وChallenge وAuthenticator Data والتوقيع. ليست مفتاحاً خاصاً، ومع تطبيق Verifier صحيح يجب أن تعمل مرة واحدة وفي Session الدخول المرتبطة فقط. لكن SpecterOps وجد أن Entra ID قبل Assertions المسجلة مجدداً ضمن نافذة زمنية محدودة. وهكذا اجتمع خطآن:

Windows logs a complete assertion
    -> an attacker reads it
    -> the verifier does not bind the challenge and assertion tightly enough to the session
    -> the same signed response is accepted again

حصل جزء Windows على CVE-2026-34348. في 14 يوليو 2026 نشرت Microsoft تحديثاً يختصر التوقيع المسجل إلى Bytes قليلة، فيزيل مصدر Replay. وأُدخل فحص Signature Counter من جهة الخادم لبعض FIDO2 Security Keys. لكن العداد ليس حماية عامة، فبعض Platform Credentials والمتزامنة تعطي صفراً دائماً أو تشارك الحالة بين أجهزة.

يتجاوز الدرس التقني السلسلة التي قُطعت الآن. لا مكان لـ WebAuthn Assertions في Diagnostic Logs أو Event Logs. يجب أن تكون Challenges عشوائية وقصيرة العمر وأحادية الاستخدام ومرتبطة بجلسة الدخول نفسها. التوقيع الصحيح وحده لا يثبت سلامة Login Flow كله.

وتخص تقنية أخرى Parent-Window-Handle في Windows WebAuthn API. تستطيع عملية محلية ترتيب مربع Passkey حقيقي بحيث يبدو تابعاً لبرنامج موثوق كالمتصفح أو البريد. واجهة النظام حقيقية، لكن السياق المشغل قد يكون مضللاً. لذا يجب التعامل مع طلبات Passkey وWindows Hello غير المتوقعة كما تُعامل MFA Push Notifications المفاجئة.

أضعف Fallback يحدد مستوى الأمان الفعلي

عرضت Proofpoint في 2025 خفض FIDO ضد Microsoft Entra ID. تظاهر Evilginx Flow معدل بأنه متصفح لا يدعم FIDO، فعرضت المنصة طرق دخول بديلة. إذا اختار الضحية SMS أو OTP أو وسيلة قابلة للتصيد، أمكن سرقة الاعتمادات والجلسة ضمن Adversary-in-the-Middle Flow.

لا يتجاوز الهجوم Origin Binding، بل يمنع WebAuthn Ceremony من البدء. ولا يعمل إلا إذا سمح الحساب إلى جانب Passkey بطريقة أضعف. ولم يوثق استغلال فعلي لهذا Downgrade.

القاعدة للمؤسسات واضحة وإن كانت غير مريحة: لا تصبح السياسة مقاومة للتصيد لمجرد تسجيل Passkey. تصبح كذلك فقط حين لا تقبل عملية الدخول لمساحة الحماية المطلوبة أي مسار بديل قابل للتصيد. وينبغي أن يدخل Recovery وHelpdesk Reset في التقييم نفسه.

المتصفح جزء من نموذج الأمان

أظهر SquareX تحت اسم Passkeys Pwned كيف يمكن لإضافة متصفح خبيثة أو Script في سياق المتصفح التأثير في navigator.credentials.create() وnavigator.credentials.get(). وتبرز مرحلة التسجيل: إذا حقن المهاجم مادة مفتاحه في اللحظة المناسبة فقد يرى المستخدم مربع Biometric حقيقياً بينما يجري في الخلفية ربط Credential تحت سيطرة المهاجم.

صدر البحث عن مزود أمني ولا ينبغي اعتباره Browser Exploit شاملاً. فالشرط المسبق كبير: يجب أن تتمكن الإضافة أو Script Context من التموضع داخل WebAuthn Path. لكن الدرس المعماري صحيح. Browser Extensions وContent Scripts ووظائف WebAuthn Proxy الشرعية جزء من Trusted Computing Base. لذلك تمثل Extension Allowlists وضبط Browser APIs المميزة حماية للهوية، لا مجرد نظافة للمتصفح.

تحمي Passkeys الدخول، لا الجلسة التالية تلقائياً

بعد نجاح الدخول تعمل الخدمة عادة بـ Session-Cookie أو Token. إذا سرق Infostealer هذا الأثر من المتصفح وقبل الخادم إعادة استخدامه من جهاز آخر، فلا يحتاج المهاجم إلى كلمة المرور أو Passkey. إنه يهاجم الجلسة الموثقة بالفعل.

هذا اليوم مسار عملي أكثر من كثير من Proofs of Concept البحثية المذكورة. تقلل Passkeys مساحة الهجوم قبل الدخول وأثناءه بوضوح، لكنها لا تعوض التخزين الآمن للـ Token، والعمر القصير والمناسب للمخاطر، وإعادة المصادقة للعمليات الحساسة، وإلغاء Tokens، وربط الجلسات عالية القيمة بالجهاز تشفيرياً حيثما أمكن.

لذلك تكون عبارة «تم تجاوز MFA» مضللة غالباً في سرقة Session. فقد اكتملت MFA بنجاح، لكن نتيجتها سُرقت بعدها.

توضح PoisonSeed سرعة تحول البحث إلى ضجيج

أعلنت Expel في يوليو 2025 أولاً هجوماً مزعوماً على Cross-Device Authentication بمفاتيح المرور. كان يفترض أن يمرر المهاجم QR-Code شرعياً إلى الضحية عبر صفحة تصيد ليستولي على الدخول عن بعد. وبعد أيام سحبت Expel الادعاء الأساسي علناً واعتذرت.

أظهر التحليل اللاحق أن فحص القرب المحلي المطلوب لـ Cross-Device Authentication لم يُتجاوز. ومن دون القرب انتهت العملية، وفشلت كل محاولات MFA، ولم يحصل المهاجم على وصول.

الحالة مفيدة جداً للنقاش الحالي. ليست كل تركيبة تبدو معقولة من QR-Code والتصيد وPasskey تجاوزاً عاملاً لـ FIDO. ويجب أن تميز الاتصالات الأمنية الجيدة بين استيلاء مرصود على حساب، وProof of Concept قابل للتكرار، وهجوم نظري، وفرضية دُحضت.

تقييمي الأمني

النطاق التقني لـ Pass-ta-key محدود. ثبتت السلسلة ضد Google Password Manager في Chrome على Windows مع TPM. واحتمال الوقوع متوسط إلى منخفض، إذ يجب أن تعمل برمجية محلياً وأن تعدل، بحسب المتغير، الحالة أو ذاكرة العملية بدقة.

أما الأثر المحتمل فمرتفع إلى مرتفع جداً. يمكن أن يؤدي النجاح إلى الاستيلاء على الحساب، أو وصول بعيد دائم، أو استخراج عدة مفاتيح خاصة. وتظل مخاطر البروتوكول منخفضة، لأن WebAuthn وOrigin Binding وPublic-Key Cryptography لم تُكسر.

بالنسبة إلى مستخدم عادي يبقى Passkey متزامن في الغالب أكثر أماناً من كلمة مرور مع SMS Code أو TOTP. فهو يزيل التصيد وCredential Stuffing وسرقة بيانات كلمات المرور القابلة لإعادة الاستخدام من مسارات واقعية كثيرة.

لكن هذه العبارة العامة لا تكفي للمسؤولين ذوي الامتياز وعمليات الموافقة المالية والوصول إلى الإنتاج والأنظمة المنظمة بشدة. ينبغي هناك أن تقرر المؤسسة صراحة هل يحقق Passkey متزامن مستوى Assurance المطلوب. وقد يكون Platform Key مرتبط بجهاز أو FIDO2 Hardware Key منفصل حداً أنسب لهذه الحسابات.

هذا ليس رفضاً لـ Sync Passkeys، بل بنية أمان متدرجة.

ما الذي يجب على مشغلي الخدمات فحصه؟

أهم درس لـ Relying Parties ليس غريباً، بل هو التحقق السليم من WebAuthn.

على الخوادم أن:

• تضبط userVerification: "required" حين تتطلب الحالة تحققاً محلياً حقيقياً من المستخدم،
• تفحص علامة UV المعادة داخل authenticatorData بصورة إلزامية،
• تتحقق بالكامل من Challenge وOrigin وRelying-Party-ID والتوقيع،
• تنشئ كل Challenge عشوائياً، وتحدد لها عمراً قصيراً، وتقبلها مرة واحدة، وتربطها بالجلسة المعنية،
• تمنع Assertions الكاملة والتوقيعات وآثار المصادقة القابلة لإعادة الاستخدام من الوصول إلى Logs،
• تسجل تسجيل Passkey وإزالته وAccount Recovery كأحداث عالية المخاطر،
• لا تسمح بـ Authenticators جديدة للحسابات المميزة إلا بعد إعادة مصادقة قوية،
• تجمع، حين يمكن، أصل Authenticator وخصائصه،
• تدرس Attestation وAuthenticators مُدارة لحالات الأمان العالي،
• تدخل تغير الجهاز والموقع الجغرافي وربط Passkey جديد في Identity Telemetry،
• تلغي Sessions بعد التغييرات الخطرة وتعيد المصادقة للعمليات الحساسة،
• تستخدم Sessions مرتبطة بجهاز عندما تدعم المنصة والتطبيق ذلك بصورة موثوقة.

تقلل مكتبة WebAuthn راسخة خطر التطبيق الذاتي الناقص، لكنها لا تعفي المشغل من فحص إعدادها. يوضح eBay كيف يمكن لعلامة واحدة غير مفحوصة أن تخفض مستوى الحماية المقصود. ويوضح Pass-the-Passkey أن توقيعاً صحيحاً يصبح عديم القيمة إذا لم ترتبط Challenge والجلسة كما يجب.

ما الذي ينبغي للمؤسسات تغييره في نشر Passkeys؟

تُخطط مشاريع Passkey غالباً كمشاريع IAM. لكن Pass-ta-key يوضح أنها مشاريع Endpoint ومتصفح وRecovery في الوقت نفسه.

تبقى Passkeys المتزامنة مناسبة لحسابات Workforce العادية. فهي تخفض عبء Helpdesk وتحمي المستخدمين بقوة من التصيد. أما الأدوار المميزة فتحتاج سياسة تفصل بوضوح حسب الحاجة إلى الحماية.

يمكن للحسابات العادية استخدام Passkeys متزامنة على أجهزة مُدارة مع Endpoint Protection وConditional Access. وللحسابات المهنية الحساسة تناسب Platform Authenticators مُدارة أو بيئات Sync محدودة ذات ربط أقوى بالجهاز. أما حسابات Admin وBreak-Glass وغيرها من الحسابات عالية القيمة فينبغي أن تستخدم FIDO2 Hardware Keys منفصلة ومرتبطة بجهاز، مع Recovery مضبوط بدقة ومن دون Cloud Sync غير محكوم.

كما ينبغي للمؤسسات:

• تحديث Chrome وWindows،
• التحقق من مستوى تحديث Windows ضد CVE-2026-34348،
• السماح أو التقييد الواعي لتخزين Passkeys في Browser Manager عبر Enterprise Policies،
• إدارة Browser Extensions بقائمة سماح ومراقبة WebAuthn Proxy Functions المميزة،
• توجيه EDR وApplication Control أيضاً إلى عمليات المستخدم،
• مراقبة الوصول إلى Browser Sync Databases وDumps لذاكرة Chrome،
• التحقيق في حذف passkey_enclave_state أو إنشائه مجدداً بصورة غير متوقعة،
• اعتبار طلبات Google-Password-Manager-Recovery-PIN المتكررة أو المفاجئة إشارة تحذير،
• اختبار عمليات فقدان الجهاز وAccount Recovery ضد الإساءة،
• إزالة Fallbacks القابلة للتصيد من الحسابات المميزة أو استبعادها بـ Authentication-Strength-Policy،
• التحقيق في Passkey Prompts المفاجئة وتسجيل Credentials جديدة واستخدام WebAuthn من عمليات غير مألوفة،
• جرد الخدمات المهمة التي تستخدم Credentials متزامنة أو مرتبطة بجهاز.

النقطة التنظيمية الحاسمة هي أن Endpoint Detection ليس بند ميزانية منفصلاً عن مشروع Passkey. عندما يعيش Authenticator في المتصفح وClient تصبح حماية Endpoint جزءاً مباشراً من نموذج المصادقة.

ما الذي ينبغي للمستخدمين فعله الآن؟

لا يوجد سبب موضوعي لحذف كل Passkeys احترازياً والعودة إلى كلمات مرور أضعف.

المفيد هو:

• تحديث Chrome وWindows سريعاً،
• تثبيت البرامج وإضافات المتصفح الموثوقة فقط،
• إبقاء حماية الجهاز وWindows Hello ومكافحة البرمجيات الخبيثة فعالة،
• عدم تأكيد مربعات Passkey أو Windows Hello غير المتوقعة،
• عدم قبول طلبات Recovery-PIN أو Re-Onboarding المفاجئة بلا تدقيق،
• فحص الأجهزة وPasskeys المسجلة في Google Password Manager والخدمات المهمة،
• التفكير في Hardware Security Key منفصل للحسابات الأعلى قيمة،
• عزل Endpoint المشتبه به وفحصه بدلاً من متابعة استخدامه.

من يجد دليلاً على برمجية خبيثة أو حالة Chrome معدلة أو Memory Dump يجب أن يفترض احتمال سرقة Credentials وSessions. لا يكفي تغيير كلمة المرور. يلزم إعادة بناء Endpoint أو تنظيف موثوق، وإلغاء Sessions النشطة، وفحص طرق Recovery، وإزالة Passkeys غير المعروفة، وتسجيل Authenticators موثوقة من جديد.

يلزم حذر خاص في حادث Golden Pass-ta-key محتمل. لا يصف البحث المنشور طريقة سهلة للمستخدم لتدوير SDS. لذلك لا ينبغي الادعاء بأن تغيير PIN أو إعادة إنشاء Passkey واحد يحل المشكلة حتماً. للحسابات المهمة، أسجل بعد تنظيف Endpoint ‏Credentials جديدة مرتبطة بجهاز، وأزيل القديمة المتزامنة، وأشرك المزود أو Incident-Response Team في الاستعادة.

الدرس الحقيقي

Passkeys ليست درعاً ضد كل اختراق. إنها تحل مشكلة كبيرة ومحددة: لم يعد الإنسان يسلم سراً قابلاً لإعادة الاستخدام إلى خادم أو موقع قد يكون مزيفاً.

يوضح Pass-ta-key المستوى التالي. عندما تتزامن المفاتيح الخاصة بسهولة بين الأجهزة، تنشأ بنية لتشفير المفاتيح وثقة الأجهزة وRecovery. ويمكن أن تحتوي هذه البنية أخطاء حتى إذا كان WebAuthn الأساسي صحيحاً.

رد الفعل الخاطئ هو إعلان فشل Passkeys. والخطأ المقابل هو اعتبار كل هجوم بعد إصابة محلية بالبرمجيات أمراً تافهاً.

لذلك يبقى تقييمي واضحاً: واصلوا نشر Passkeys، لكن صيغوا وعود الأمان بدقة. Passkeys المتزامنة ممتازة ضد التصيد. وتقدم Hardware Keys المرتبطة بجهاز حداً أقوى للحسابات عالية القيمة. ولا يعوض أي Authenticator عن Endpoint نظيف، وRecovery مضبوط، وفحوص خادم مطبقة بصورة صحيحة.

لقد أغلقت Passkeys باب التصيد بإحكام أكبر بكثير. ويذكرنا Pass-ta-key بأن المهاجم الموجود داخل المنزل يحتاج إلى دفاع آخر.

إلى اللقاء في المرة القادمة،
Joe

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