كشفت دراسة حديثة عن بنية “كلمات المرور الخفية” (Passkeys) في Google Authenticator عن وجود طبقة سحابية تعمل خلف الكواليس، مما قد يفتح الباب أمام ثغرات أمنية جديدة لطرق المصادقة الحديثة. يسلط هذا الاكتشاف الضوء على تعقيدات نظام كلمات المرور الخفية الذي وعد بتعزيز الأمان.
يهدف نظام كلمات المرور الخفية إلى استبدال كلمات المرور التقليدية بمفاتيح تشفير مرتبطة بأجهزة المستخدم، مما يعزز الأمن ويحد من مخاطر اختراق الحسابات. ومع ذلك، فإن تفاصيل التنفيذ الفعلي لهذا النظام قد تحمل تحديات غير متوقعة.
فهم بنية المصادقة السحابية لكلمات المرور الخفية
على عكس المصادقات التقليدية التي ترتبط بجهاز واحد، فإن نظام كلمات المرور الخفية المدعوم بـ Google Password Manager (GPM) يعتمد على مكون سحابي. يقوم متصفح Chrome، عند كل تسجيل دخول باستخدام كلمات المرور الخفية، بالاتصال بخدمة سحابية تعمل على معالجة عمليات التشفير الحساسة.
تتولى هذه الخدمة السحابية، التي تعمل تحت نطاق “enclave.ua5v[.]com”، مسؤولية إنشاء مفاتيح كلمة المرور الخفية، ومعالجة طلبات المصادقة، وضمان المزامنة بين جميع أجهزة المستخدم المسجلة. وعلى الرغم من أهميتها، فإن دور هذا النطاق لم يكن موثقاً بشكل كافٍ علناً كقوة دافعة لعمليات تسجيل الدخول العالمية.
آلية عمل المصادقة السحابية
كشف باحثو Unit 42 عن هذا الهيكل السحابي أثناء مراجعة أمنية معمقة لتطبيق Google لكلمات المرور الخفية. بدلاً من التركيز على بروتوكول FIDO نفسه، قاموا بتحليل مكان تخزين كلمات المرور الخفية، وكيفية انتقالها بين الأجهزة، وأي المكونات تحمل المواد الرئيسية الأكثر حساسية.
ينتج عن هذا النهج سطح هجوم واسع، ولا تصف الوثائق الفنية لـ FIDO و W3C هذا السطح بالكامل أو تعالجه بشكل كافٍ. تعتمد البنية على عملية تسجيل الأجهزة التي تعمل في الخلفية قبل استخدام كلمات المرور الخفية.
عملية تسجيل الجهاز
تقوم Chrome بإنشاء زوجين من المفاتيح المدعومة بالأجهزة باستخدام الوحدة النمطية للنظام الموثوق (TPM) بالجهاز. يتم تسجيل هذه المفاتيح، المفتاح التعريفي ومفتاح التحقق من المستخدم، مع المصادق السحابي.
يقوم المصادق السحابي بتخزين هذه المفاتيح العامة، ويخصص مفتاح تغليف خاص بالجهاز، ويصدر زوج مفاتيح عضو لإضفاء الشرعية على الجهاز كمشارك موثوق به في مجال أمان المستخدم. يتم حفظ الحالة الكاملة لهذه العملية محليًا في ملف يسمى “passkey_enclave_state”، والمخزن داخل دليل ملف تعريف Chrome.
نموذج هجين وتركيز السلطة التشفيرية
هذه البنية تخلق نموذجًا هجينًا لا يتم فيه تخزين مفاتيح كلمات المرور الخفية الخاصة بشكل مباشر على الجهاز في شكل قابل للاستخدام. بدلاً من ذلك، يتم تشفيرها باستخدام سر مجال الأمان (SDS) الذي يديره المصادق السحابي. يتطلب كل تسجيل دخول إرسال SDS المغلف إلى السحابة، حيث يتم فك تشفيره واستخدامه للتوقيع على استجابة المصادقة نيابة عن الجهاز.
هذا يضع ثقة كبيرة في المكون السحابي، ويثير تساؤلات حول ما قد يحدث إذا أصبح هذا المكون السحابي هدفًا للهجمات. وبينما يهدف البروتوكول إلى تعزيز الأمان، فإن هذا التنفيذ يشير إلى وجود نقاط ضعف محتملة.
تداعيات أمنية وطرق الحماية
يعتمد الاتصال بين Chrome والمصادق السحابي على بروتوكول Noise، باستخدام إصدار محدد من المصافحة (Noise_NK_P256_AESGCM_SHA256). تفتح Chrome اتصال WebSocket بنطاق “enclave.ua5v[.]com”، وتجري تبادل مفاتيح Diffie-Hellman لإنشاء مفتاح جلسة مشترك.
في كل طلب لاحق، يتم التوقيع باستخدام مفتاح الجهاز المدعوم بوحدة TPM.
عملية تسجيل الدخول عبر السحابة
أثناء عملية تسجيل الدخول بكلمة مرور خفية، ترسل Chrome الأمر “passkeys/assert” مع معرف الجهاز و SDS المغلف. يقوم المصادق السحابي بفك تشفير SDS، وفك تشفير مفتاح كلمة المرور الخفية الخاصة، وبناء استجابة المصادقة، والتوقيع عليها قبل إعادتها إلى Chrome. تقوم المتصفح بعد ذلك بتمرير هذه الاستجابة إلى الطرف المعتمد، الذي يتحقق من التوقيع ويُكمل تسجيل الدخول.
قد يشكل هذا التصميم، الذي يركز السلطة التشفيرية في بيئة سحابية عن بعد، خطرًا إذا تم اختراق هذه البيئة أو انتحال هويتها. يمكن للمهاجمين، في هذه الحالة، توليد استجابات مصادقة صالحة نيابة عن أي مستخدم مسجل.
تنصح المنظمات والأفراد الذين يعتمدون على كلمات المرور الخفية المتزامنة عبر GPM بمراقبة حسابات Google الخاصة بهم بحثًا عن أي تسجيلات أجهزة غير متوقعة. كما يُنصح بتدقيق سجلات المصادقة بانتظام بحثًا عن أنماط وصول غير طبيعية، والنظر في استخدام مفاتيح الأمان المادية المتوافقة مع FIDO2 للحسابات ذات الامتيازات العالية أو الحساسة، بدلاً من كلمات المرور الخفية المتزامنة عبر السحابة.