أبرز أنماط إساءة استخدام التشفير

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

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

أصبح كسر التصادمات في MD5 ممكنًا منذ عام 2004؛ إذ إن إنشاء ملفين لهما تجزئة MD5 نفسها أمر سهل حسابيًا. وقد أُثبتت عمليًا هجمات التصادم على SHA-1 من خلال هجوم SHAttered الذي نفذته Google عام 2017، إذ أُنشئ ملفا PDF لهما تجزئة SHA-1 نفسها. ولا ينبغي استخدام أي منهما لأي غرض أمني، مثل التواقيع الرقمية أو سلامة المحتوى أو تخزين كلمات المرور أو HMAC. استخدم SHA-256 أو SHA-3 أو BLAKE2 في عمليات النشر الحديثة.

يُعد استخدام ‎time()‎ أو قيم أخرى قابلة للتنبؤ لتهيئة مولّد أرقام شبه عشوائية ثغرةً خطيرة عندما تُستخدم مخرجات PRNG لأغراض أمنية. فإذا عرف المهاجم تقريبًا وقت إنشاء المفتاح، فبإمكانه تجربة جميع البذور في نطاق زمني صغير لاستعادة المفتاح. ومن الأمثلة الكلاسيكية أن الإصدارات المبكرة من Netscape كانت تهيئ إنشاء مفاتيح SSL باستخدام الوقت ومعرّف العملية، وكان كلاهما قابلًا للمراقبة من قبل مهاجم على الجهاز نفسه.

يستخدم ‎rand()‎ في C و‎java.util.Random‎ ووحدة ‎random‎ في Python مولدات خطية توافقية حتمية أو Mersenne Twister، وقد صُممت هذه المولدات لجودة إحصائية في المحاكاة، لا للأمان. ويمكن لمهاجم يراقب عددًا كافيًا من مخرجات هذه المولدات إعادة بناء حالتها الداخلية والتنبؤ بجميع المخرجات المستقبلية. وللأغراض الأمنية، استخدم مولدات CSPRNG التي يوفرها نظام التشغيل: ‎secrets.token_bytes()‎ في Python أو ‎crypto.randomBytes()‎ في Node.js أو ‎/dev/urandom‎ في Linux.

لا يوفر التشفير دون مصادقة سوى السرية، ولا يضمن السلامة. فحتى إذا تعذر على المهاجم قراءة النص الصريح، يمكنه تعديل النص المشفر، مما قد يسبب تغييرات يمكن التنبؤ بها في النص الصريح، ولا سيما في وضعي CTR أو CBC. ويتيح هذا التعديل شن هجمات؛ فالمهاجم الذي يعترض معاملة مصرفية مشفرة قد يقلب بعض البتات لتغيير مبلغ التحويل أو الحساب المستفيد من دون معرفة النص الصريح. استخدم دائمًا التشفير الموثّق (AEAD).

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

يؤدي استخدام متجه التهيئة نفسه لعمليات تشفير متعددة باستخدام المفتاح نفسه إلى ثغرات خطيرة. ففي وضع CTR، تؤدي إعادة استخدام IV إلى إنشاء تيار مفاتيح نفسه، مما يتيح استعادة النص الصريح باستخدام XOR. وفي وضع CBC، تتيح إعادة استخدام IV للمهاجم اكتشاف ما إذا كانت رسالتان تبدآن بكتل نص صريح متطابقة. أما في GCM، فإن إعادة استخدام nonce (IV) كارثية، كما يوضح درس إعادة استخدام nonce. أنشئ IV عشوائيًا جديدًا لكل عملية تشفير، وألحقه بالنص المشفر لتخزينه مع سياق فك التشفير.

يُعد تخزين كلمات المرور بعد تجزئتها باستخدام MD5 أو SHA-256 أو أي دالة تجزئة تشفيرية سريعة أخرى غير كافٍ. إذ تستطيع وحدات معالجة الرسوميات الحديثة حساب مليارات تجزئات SHA-256 في الثانية، مما يجعل هجمات القوة الغاشمة غير المتصلة بقواعد بيانات التجزئات المسروقة سريعةً للغاية. وتتطلب تجزئة كلمات المرور دوال بطيئة ومصممة خصيصًا وتحتاج إلى قدر كبير من الذاكرة، مثل bcrypt أو scrypt أو Argon2id. وقد صُممت هذه الدوال لجعل هجمات القوة الغاشمة مكلفة حتى باستخدام عتاد متخصص، بحيث تصبح الهجمات غير المتصلة غير عملية حسابيًا.

يؤدي تعطيل التحقق من شهادات SSL/TLS، مثل ضبط ‎ssl.CERT_NONE‎ في Python أو تمرير ‎-k‎ إلى curl أو ضبط ‎trustAllCerts=true‎ في Android، إلى إزالة الحماية من هجمات الرجل في الوسط. ويمكن للمهاجم تقديم أي شهادة واعتراض جميع الاتصالات. وتظهر هذه الممارسة في التطوير لتجاوز أخطاء الشهادات الموقعة ذاتيًا، لكنها غالبًا ما تستمر حتى بيئة الإنتاج. استخدم دائمًا التحقق الصحيح من الشهادات، وأصلح مشكلات الشهادات الأساسية بالطريقة السليمة.

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

لماذا يُعد وضع ECB (دفتر الرموز الإلكتروني) غير آمن لتشفير البيانات؟

أهم أنماط إساءة الاستخدام التي يجب تجنبها: لا تستخدم وضع ECB مطلقًا لأنه يسرّب أنماط الكتل؛ ولا تنفذ بدائيات التشفير بنفسك؛ وارفض MD5 وSHA-1 لأغراض الأمان؛ وهيّئ PRNG باستخدام CSPRNG لا ‎time()‎؛ واستخدم CSPRNG لكل عشوائية حساسة أمنيًا؛ ووثّق دائمًا البيانات المشفرة باستخدام AEAD؛ ولا تضمّن المفاتيح أو IVs في التعليمات البرمجية مطلقًا؛ وأنشئ IV جديدًا لكل عملية تشفير؛ واستخدم Argon2id لكلمات المرور بدلًا من دوال التجزئة السريعة؛ وتحقق دائمًا من شهادات TLS؛ وتحقق من كل قيمة مُعادة من دوال التشفير.