ثغرات المصادقة الرقمية: الحاجة المُلحة لآليات مبتكرة

مقدمة: كلمة السر، حارس الأسرار القديم

لطالما كانت كلمات السر هي الحارس الأسمى للتنوع والأمان. منذ العصور الرومانية القديمة وحتى يومنا هذا، تُستخدم كلمات السر لإثبات أحقية الفرد في الحصول على امتياز لا يمتلكه الآخرون، وإن كانوا يرغبون بشدة في الحصول عليه. إن “الكلمة السحرية” التي يعرفها شخص دون غيره تفتح له باب الفرص وتميزه عن الحشود الهائلة.

يمكننا القول إن كلمة السر هي أقدم وأوسع دعائم المصادقة استخدامًا، وما زالت تُستخدم على نطاق واسع في إنترنت القرن الحادي والعشرين. تزداد أهميتها اليوم أكثر من أي وقت مضى، فمع تزايد أعداد الأشخاص الذين يتواصلون عن بُعد دون رؤية أو سماع بعضهم البعض، ومع استخدام الوسائل البعيدة للوصول إلى الأنظمة الآلية، يصبح الاعتماد على كلمات السر أمرًا حاسمًا للتحقق من الطرف البعيد وإثبات الهوية الشخصية. فمجرد معرفة كلمة سر شخص آخر يتيح لك أن تصبح ذلك الشخص في نظر الآخرين، وتفعل ما يحلو لك باسمه، وتحصل على امتيازاته في الأنظمة الآلية. لهذا السبب، من الضروري حماية كلمات السر بشكل صحيح.

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

التواصل كتهديد رئيسي للأسرار

الطريقة المثالية للحفاظ على سر آمن هي عدم استخدامه؛ فإذا لم تستخدمه أبدًا، فلن يتم اعتراضه أبدًا. لكن هذا يجعل هذه الأسرار عديمة الفائدة. وبما أن الأسرار تمنحك امتيازات، فإنك ترغب في الحصول على هذه الامتيازات وممارستها بين الحين والآخر. وللقيام بذلك، عليك إثبات أنك تعرف السر. تتضمن هذه العملية إرسال السر إلى طرف آخر، مما يؤدي في النهاية إلى كشف السر كليًا أو جزئيًا.

تتضمن ممارسة السر طرفين على الأقل: المُثبِت (أنت) والمُتحقِّق (الكيان الذي يقرر في النهاية ما إذا كان سرك صحيحًا وأنك تستحق الامتيازات التي تدعيها). ومع ذلك، إذا لم تتمكن من التواصل مع المُتحقِّق مباشرة، فسيتعين عليك استخدام كيان وسيط واحد أو أكثر، وفي هذه الحالة، ستعرف هذه الكيانات السر أيضًا. لنعد الآن إلى عالم الواقع في القرن الحادي والعشرين والإنترنت: أثناء التواصل، قد تستخدم آلاف الروابط الوسيطة لتسليم بياناتك، لذا بمجرد إرسال سر إلى المُتحقِّق، فإنه لم يعد سرًا بعد الآن.

الأساليب الحالية للمصادقة: تطور التحديات

توفر الأساليب الحالية مستوى معينًا من الحماية – أفضل أو أسوأ – ولكن لكل منها عيوب كبيرة. حتى الآن، استخدمت معظم الأنظمة الحالية والبروتوكولات الآمنة ثلاثة أنواع فقط من البدائيات التشفيرية: التشفير (encryption)، واتفاق المفاتيح (key agreement)، والتوقيعات الرقمية (digital signatures). أما المهام الأكثر تعقيدًا، مثل المصادقة (authentication)، فيتم تحقيقها من خلال دمج هذه البدائيات بطريقة ما في بروتوكول.

بدأت مصادقة الإنترنت بكلمات سر بسيطة جدًا: يدخل المستخدم كلمة السر في نموذج الويب، وتُرسل كلمة السر عبر HTTP إلى الخادم، ثم يتحقق الخادم من كلمة السر ويسمح للمستخدم بالدخول. كان ذلك في الأيام الأولى للإنترنت الصغير، حيث كان المهاجمون مقيدين بخبرة قليلة جدًا حول كيفية عمل الإنترنت. وحتى لو كان لدى البعض معرفة أساسية بالشبكات، لم يكن لديهم المعدات أو الأدوات أو البرامج (التي كانت باهظة الثمن في ذلك الوقت) لتنفيذ الهجمات. كما كانت الهجمات نفسها بلا جدوى بسبب القيمة التجارية الضئيلة للمعلومات التي كانت تمر عبر الإنترنت في ذلك الوقت.

في نهاية المطاف، أدى نمو الإنترنت وتوفر المعرفة والبرامج والأدوات إلى ظهور أول مهاجم شبكي: سُرقت كلمات سر HTTP بسهولة بواسطة أبسط أدوات التجسس السلبية على الشبكة (passive network sniffers) ومحللات البروتوكولات (protocol analyzers). كانت الخطوة التالية هي تغيير كلمات السر إلى قيم لا فائدة منها للمتجسسين السلبيين: بدأ الناس في تجزئة كلمة السر (hashing the password). بما أن الخادم والمستخدم كانا يمتلكان نفس كلمة السر، يمكنهما إنتاج تجزئات متطابقة ومقارنتها، مع إرسال المستخدم التجزئة إلى الخادم. بدا الأمر وكأن المهاجمين لا يستطيعون الحصول على كلمة السر، لأن عكس دالة التجزئة (hash function) “شبه مستحيل” حسابيًا. هذا الحل أنقذ الموقف… لفترة وجيزة فقط!

استخدم المهاجمون طريقتين للتغلب على ذلك:

1. أولاً: يميل الكثير من الناس إلى جعل كلمات سرهم “سهلة التذكر”، لذا قام المهاجمون بتجزئة مجموعة كبيرة من الكلمات الشائعة، وبمعرفة التجزئة، يمكنهم بسهولة “البحث” عن كلمة السر الأصلية إذا كانت من “القاموس” الذي تم إنتاجه: وهكذا تم اختراع هجوم القاموس (dictionary attack).
2. ثانيًا: حتى لو استخدم شخص ما كلمة سر معقدة، استخدم المهاجمون التجزئة مباشرة للمصادقة مع الخادم باستخدام “متصفح معدّل”. لم يدخلوا كلمة السر في النموذج، بل حقنوا التجزئة مباشرة في تدفق HTTP: وهكذا تم اختراع الهجوم النشط (active attack).

أصبح واضحًا الآن أن حركة مرور HTTP يجب أن تكون مشفرة. ومع ذلك، نظرًا لأن الأطراف المتواصلة كانت بعيدة عن بعضها البعض، فقد تم استخدام اتفاق المفاتيح (key agreement) والذي تم اختراقه في النهاية من قبل المهاجمين: تم اقتراح هجوم الوسيط (man-in-the-middle). يستمر التاريخ: كلما تم اقتراح آليات أكثر تعقيدًا لحماية نقل كلمات السر، تم تصميم هجمات أفضل وأكثر ذكاءً للتغلب عليها. ألن يكون رائعًا تجنب إرسال كلمات السر على الإطلاق؟

استعراض أبرز آليات المصادقة الحالية ونقاط ضعفها

1. بروتوكولات تبادل التجزئة المخصصة (Custom hash exchange protocols)

يبدو معظم المهندسين الذين يبدأون للتو في تطوير أدوات التشفير سعداء للغاية عندما يحققون أول نجاح لهم في تحويل جزء من البيانات إلى سلسلة عشوائية المظهر باستخدام مفتاح، واستعادة البيانات الأصلية. المشكلة هي أن معظم المهندسين يتوقفون عند هذه النقطة. وكما نعلم من قانون شنيير (Schneier’s law): “يمكن لأي شخص، من الهواة الأكثر جهلاً إلى أفضل خبراء التشفير، إنشاء خوارزمية لا يستطيع هو نفسه كسرها.”

يعتقدون أنه إذا كان الإخراج يبدو عشوائيًا بالفعل ولا أحد يعرف المفتاح، فهم في أمان. لذلك، يمكن للمرء دائمًا العثور على آليات تشفير منخفضة الأمان، ومفاتيح مشفرة بشكل ثابت (hardcoded keys)، أو متجهات تهيئة غير صحيحة (improper usage of initial vectors)، أو استخدام غير سليم لأنماط التشفير (encryption modes) وما إلى ذلك، حتى في برامج الإنتاج. ورغم أن إخراجك يبدو عشوائيًا، فإن مهاجمًا متطورًا يمتلك الأدوات والخلفية الرياضية المناسبة سيجد بالتأكيد أنماطًا، وتسريبات قنوات جانبية (side-channel leaks)، ويقوم بتحليل التشفير (cryptanalysis)، وفي النهاية سيستعيد البيانات. حتى الشركات الكبيرة تقع في مشاكل بسبب هذا، فما الذي يجعلك مميزًا؟

توفر المخططات المختلفة التي تتضمن bcrypt أو pbkdf2 أو أي أطر عمل “تشفير ثم مقارنة” (encrypt then compare) جزءًا فقط من نظام الأمان بدلاً من حل كامل. وهذا لا يوفر مستوى كافيًا من الأمان على الإطلاق.

2. مصادقة HTTP

لا تزال كلمات السر تُستخدم على نطاق واسع في HTTP لمنح المستخدمين الوصول إلى الموارد المقيدة. ومع ذلك، على الرغم من التاريخ الطويل لتحديثات بروتوكولات المصادقة، لا يزال هناك مجال للهجمات. لن يحاول المستخدم الواعي أمنيًا أبدًا إدخال كلمة السر الخاصة به على موقع ويب إذا لم يوفر هذا الموقع اتصال HTTPS لإدخال هذه البيانات. هذا يعني أنه حتى اليوم، آليات مصادقة HTTP بحد ذاتها ضعيفة جدًا.

دعنا نلقي نظرة مبسطة وعالية المستوى على مصادقة HTTP:

للوهلة الأولى، يبدو الأمر جيدًا، ولكن عند التفكير مليًا، قد تتبادر إلى الذهن العديد من المخاوف:

• أولاً وقبل كل شيء، الخادم يصادق العميل، لكن العميل لا يصادق الخادم. لذا لا يملك العميل أي فكرة عن الجهة التي يرسل إليها بيانات اعتماده.
• علاوة على ذلك، لا تحدد مصادقة HTTP السرية (confidentiality)، لذا يمكن لأي شخص على الأقل معرفة أن مورد ويب معين لديه قاعدة مستخدمين معينة بمجرد مراقبة حركة المرور.
• على الرغم من أن المستخدمين في بروتوكولات المصادقة الحديثة لا يرسلون كلمات السر مباشرة، بل يرسلون تجزئات (hashes) لكلمات السر (وهي دالة أحادية الاتجاه لا رجعة فيها)، لا يزال بإمكان المتجسسين السلبيين (passive eavesdroppers) جمع هذه المعلومات واستخدام تقنيات أكثر تعقيدًا (مثل هجمات القاموس dictionary attacks لاستعادة كلمة السر).
• لم تستخدم آليات المصادقة السابقة قيم nonce من جانب الخادم، لذا كان هجوم إعادة التشغيل (replay attack) البسيط ممكنًا. حتى اليوم، تدعم العديد من المتصفحات هذه الآليات القديمة لأسباب التوافق، لذا يمكن لمهاجم الوسيط (man-in-the-middle) تزوير الرسائل بين العميل والخادم وتنفيذ هجوم تخفيض المستوى (downgrade attack).

3. كيربيروس (Kerberos)

نهج كسول: بدلاً من أن يصادق كل طرف الآخر، لماذا لا نجعل طرفًا ثالثًا يقوم بذلك؟ لذا يتم إنشاء كيان، وتسجل جميع العملاء والخدمات مفاتيحها هناك، وعند الحاجة إلى التواصل بين عميل وخادم معينين، فإنهم “يطلبون الخدمة” ببساطة. يبدو جيدًا في البداية، ولكن هناك عيوب، وأهمها أن جميع العيوب تتفاقم سوءًا مع نمو بنيتك التحتية:

• طرق ضعيفة التطور للحصول على الثقة الأولية لخادم Kerberos (تسجيل العميل والخدمة الأولي).
• يُستخدم التشفير المتماثل (symmetric encryption) في الغالب لمعلومات البروتوكول، وبما أن البروتوكول معروف، فهناك إمكانية مفتوحة لهجمات النص الواضح المعروف (known-plaintext attacks).
• التطوير والاختبار صعبان تحت نظام Kerberos: يتطلب بيئة تطوير وبيئة إنتاج منفصلتين وإعداد Kerberos منفصلًا لكل منهما.
• احتمال وجود إعدادات خاطئة (misconfigurations) واستخدام تشفير ضعيف للمسؤولين غير المتمرسين.
• الأهم من ذلك: كل شيء يسير على ما يرام طالما أن خادم Kerberos آمن. عندما يتم اختراقه، ينفجر النظام الأمني بأكمله. وبما أن الاختراقات الأمنية تحدث عاجلاً أم آجلاً، فإن وجود Kerberos يشبه امتلاك قنبلة موقوتة أمنية في فنائك الخلفي.

4. SSL/TLS

يعتبر SSL/TLS البروتوكول المعياري الفعلي (de facto standard protocol) للمصادقة عبر الإنترنت. باستخدام TLS، يصادق العميل (على سبيل المثال، المتصفح) الخادم، وبشكل اختياري، قد يصادق الخادم العميل. البروتوكول راسخ جيدًا، ولكنه يحمل بعض العيوب:

• يتطلب بنية تحتية للمفاتيح العامة (Public Key Infrastructure - PKI) راسخة، وهي صعبة الإعداد والصيانة تقنيًا ومكلفة أيضًا.
• البروتوكول معقد، لذا فإن قابليته للتدقيق (audit-ability) ضعيفة من حيث التنفيذ (تثبت ذلك العديد من هجمات التنفيذ implementation attacks).
• له تاريخ طويل من التحديثات والتحسينات، التي تدفعها أسباب التوافق بالإضافة إلى هجمات البروتوكول المكتشفة.
• لا يزال لديه نقاط ضعف (جزئيًا بسبب ما سبق).

على الرغم من أن الإصدار الحالي يعتبر آمنًا (إلا أن الناس نادرًا ما يستخدمون أحدث إصدار من TLS، وبدلاً من ذلك يغرقون في التشفيرات القديمة والإصدارات الضعيفة مثل SSLv3)، لا يزال هناك العديد من المعلومات التي يمكن للمراقب السلبي جمعها من نتائج البروتوكول:

• ما إذا كان البروتوكول قد نجح أم لا.
• الأطراف التي تتواصل (عن طريق فحص حقول الشهادة certificate fields).
• مدى حداثة البرامج على العميل والخادم (عن طريق فحص إصدار TLS المتواصل وقائمة مجموعات التشفير المدعومة supported cipher suites).
• ربما ما إذا كانت الأطراف تستخدم أجهزة مخصصة لتخزين المفتاح الخاص (private key storage).

5. OAuth

قد يعتقد المرء أننا أغفلنا OAuth، وهو بروتوكول التفويض المفوض (Delegated Authorization protocol) الشائع الاستخدام للمصادقة في الوقت الحاضر. ومع ذلك، فهو بروتوكول:

• استقال أحد مصمميه الرئيسيين مع تعليقات سلبية تجاه مستوى الأمان.
• تم العثور على العديد من العيوب في تصميمه الأساسي (core design).
• أنماط أخطاء تنفيذ متعددة (numerous implementation error patterns) … تطفو بين عمليات النشر الكبيرة مثل Github و Facebook.

باختصار، قد تجمع كل أسوأ النقاط من الطرق السابقة (العملاء غير المصادق عليهم، أمان النقل السيئ)، وتضيف نقاطًا جديدة (هجمات جانبية نشطة active side attacks!)، وتحصل على ذلك كبروتوكول “مصادقة”. إذا اضطررت، لأي سبب من سوء الحظ، إلى استخدام OAuth للمصادقة، فيرجى استثمار بعض الوقت في تعزيز أمانه قدر الإمكان.

تحديات جديدة وحلول غير كافية

مع تزايد التعقيد، تظهر مشاكل جديدة. وبصرف النظر عن المشاكل المتعلقة بالبروتوكولات نفسها، تظهر مخططات جديدة لشبكات وتوزيع العلاقات، مع تخطيطات شبكية مخصصة (ad-hoc network layouts)، وأدوار مختلطة، وقدرة قليلة على حمل بنية تحتية ثقيلة للثقة من الماضي. أنواع جديدة من الثغرات الأمنية (vulnerability types) وتقنيات جديدة للكشف عن الثغرات تجعل متجهات الهجوم (attack vectors) الجديدة فعالة.

ماذا نفعل لمعالجة هذه التحديات؟ ليس الكثير. نزيد التعقيد أكثر من خلال إدخال المصادقة متعددة العوامل (multi-factor authentication). نضيف رموز مصادقة بخصائص سيئة حقًا (مثل بصمات الأصابع، التي يتم تصويرها بكاميرا خاصة في جهاز iPhone الخاص بك). نقدم أجهزة مادية. ومع ذلك، مع وجود عيوب خاصة بكل قناة من قنوات المصادقة هذه، في حين أن القوة العامة للمخطط بأكمله تكون أفضل عندما يكون كل جزء قويًا بما فيه الكفاية، إلا أنه عندما يتم اختراق أي من قنوات المصادقة، يتدهور الأمان بشكل كبير. وبما أن البنية التحتية لقنوات المصادقة الجديدة هذه لم تستقر بعد، فقد لا تدرك حتى أن رمزك قد تم اختراقه، جنبًا إلى جنب مع مخطط المصادقة بأكمله.

هل من حل؟

جميع الطرق المذكورة أعلاه قوية إلى حد ما، ولها نقاط ضعف مختلفة. إذا كنت ترغب في التمسك بهذه الطرق، فعلى الأقل ابذل بعض الجهد في حمايتها من نقاط ضعفها من خلال تطبيق أفضل الممارسات المتاحة. كخبراء تشفير، نسعى جاهدين لابتكار طرق آمنة نظريًا، وليس فقط “لم يثبت عدم أمانها أبدًا”، وهو ما يُعرف بأنه آمن عمليًا (practically secure).

ومع ذلك، لدينا شيء أكثر إثارة للاهتمام للأشخاص الراغبين في تجربة أشياء جديدة. شيء ليس قويًا عمليًا فحسب، بل قويًا رياضيًا أيضًا. في Cossack Labs، كنا نعمل على آلية مصادقة طلبات مبتكرة (novel request authentication scheme)، فعالة عندما يكون هناك معرف كائن (A) وخاصية فريدة للكائن (B). من بين هذه الكائنات، ليس من المستغرب، أزواج تسجيل الدخول/كلمة السر (login/password pairs). لا تعتمد هذه الطريقة على خصائص التشفير التقليدية، التي لا تزال تتضمن إرسال كلمات السر بشكل أو بآخر عبر الشبكة (مع وجود احتمال نظري لاختراقها)، ولكنها تطبيق عملي تمامًا لأسس رياضية تشفيرية مبتكرة لا تسرب بيانات الاعتماد على الإطلاق، سواء بشكل مباشر أو في شكل مجزأ (hashed form). ترقبوا المقالات التعليمية والأوراق العلمية القادمة حول Secure Authenticator، وهي طريقة جديدة للتحقق من كلمة سر المستخدم مع فرصة 0% لاعتراضها.