bcrypt مقابل Argon2: اختيار إعدادات تجزئة كلمات السر

المشكلة التي تحلها تجزئة كلمات السر

تسمح تجزئة كلمات السر للواجهة الخلفية بتخزين كلمة السر دون حفظها فعليًا. عندما يسجل شخص ما، تجري الخادم عملية تجزئة على كلمة السر وتخزن النتيجة (الهاش). عند تسجيل الدخول، تُجزأ كلمة السر التي أدخلها المستخدم وتُقارن بالنتيجة المخزنة.

التجزئة ليست تشفيرًا. لا توجد طريقة لفكها. هذه الخاصية باتجاه واحد هي بالضبط سبب استخدام التجزئة لكلمات السر.

فلماذا لا نستخدم هاش سريع مثل SHA-256؟ لأن السرعة هي ما يريده المهاجمون. إذا سُرقت قاعدة بيانات، لا يخمن المهاجمون كلمات السر بتجربة تسجيل دخول واحدة في كل مرة. هم يخمنون في وضع عدم الاتصال، ويشغِّلون التخمينات بأسرع ما تسمح به أجهزتهم. مع وحدات معالجة الرسوميات، يمكن اختبار الهاشات السريعة بمقاييس هائلة. حتى مع وجود salts فريدة، يظل الهاش السريع رخيصًا للهجوم بالقوة الغاشمة.

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

تجزئة كلمات سر جيدة تجعل التخمين مكلفًا. الهدف ليس "غير قابل للكسر"، بل "بطيء ومكلف لدرجة لا تستحق الجهد".

إعداد تجزئة كلمات السر يجب أن يكون:

• أحادي الاتجاه (للتحقق، ليس للعكس)
• بطيئًا لكل تخمين
• مكلفًا بالنسبة للأجهزة المتوازية (خاصة GPUs)
• سريعًا بما يكفي ليشعر المستخدم بأن تسجيل الدخول طبيعي
• قابلًا للتعديل حتى ترفع التكلفة مع الوقت

bcrypt و Argon2 في دقيقة

عند المقارنة بين bcrypt و Argon2، تختار كيف تريد إبطاء التخمين بعد تسرب قاعدة البيانات.

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

Argon2 أقدم لتصميمه المقاوم للذاكرة. يمكنه إجبار كل تخمين على استخدام قدر كبير من الذاكرة وليس فقط CPU. هذا مهم لأن المهاجمين غالبًا يفوزون بتشغيل عدد هائل من التخمينات المتوازية على GPUs أو أجهزة متخصصة. الذاكرة أصعب وأغلى للتوسع بهذا المستوى من التوازي.

لـ Argon2 ثلاث متغيرات:

• Argon2i: يركّز على المقاومة لبعض هجمات القناة الجانبية
• Argon2d: يركّز على مقاومة GPUs مع اعتبارات القناة الجانبية
• Argon2id: مزيج عملي من الاثنين، والافتراضي الشائع لتجزئة كلمات السر

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

خصائص الأمان الأكثر أهمية

السؤال الجوهرِي بسيط: إذا سرق مهاجم قاعدة كلمات السر، كم تكون تكلفة تخمين كلمات السر على نطاق واسع؟

مع bcrypt تسيطر على التكلفة (عامل العمل). ارتفاع العامل يعني أن كل تخمين يستغرق وقتًا أطول. هذا يبطئ المهاجمين ويبطئ أيضًا فحوصات تسجيل الدخول لديك، لذا تضبطه عند نقطة تكون مؤلمة للمهاجمين لكنها مقبولة للمستخدمين.

مع Argon2id يمكنك إضافة "مقاومة الذاكرة" فوق تكلفة الزمن. كل تخمين يحتاج وقت CPU وذاكرة تُستخدم بنمط محدد. يمكن أن تكون GPUs سريعة جدًا في الأعمال المحوسبة، لكنها تفقد الكثير من ميزتها عندما يحتاج كل تخمين متوازٍ لذاكرة كبيرة.

الـ salts غير قابلة للتفاوض. قيمة عشوائية وفريدة لكل كلمة سر:

• تمنع إعادة استخدام جداول محسوبة مسبقًا عبر قاعدة البيانات
• تضمن أن كلمات السر المتطابقة لا تعطي نفس الهاش بين المستخدمين

الـ salts لا تجعل كلمات سر ضعيفة قوية. هي تحميك بعد تسرب قاعدة البيانات بإجبار المهاجم على عمل حقيقي لكل مستخدم.

نقاط قوة bcrypt وحدوده التي يجب معرفتها

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

أكبر مفاجأة هي حد 72 بايت لكلمة السر. bcrypt يستخدم فقط أول 72 بايت من كلمة السر ويتجاهل الباقي. هذا قد يفاجئ من يستخدمون عبارات مرور طويلة أو مديري كلمات السر.

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

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

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

نقاط قوة Argon2 ومقايضاتها

صُمم Argon2 لتجزئة كلمات السر. يختار معظم الفرق Argon2id لأنه يوازن مقاومة GPUs مع حماية معقولة ضد هجمات القناة الجانبية.

يعطيك Argon2id ثلاث معلمات:

• الذاكرة (m): مقدار RAM الذي يستخدمه كل هاش أثناء التشغيل
• الزمن/التكرارات (t): عدد المرات التي يجتاز فيها الذاكرة
• التوازي (p): عدد القنوات التي يستخدمها (يفيد على وحدات CPU متعددة النوى)

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

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

للحفاظ على Argon2id آمنًا ومناسبًا للاستخدام، اضبطه كميزة أداء:

• اختبر القياس على أجهزة تشبه الإنتاج
• حد من العمل المتوازي للتجزئة (حدود العمال، قوائم انتظار)
• حد محاولات تسجيل الدخول وعرقل المحاولات المتكررة
• احتفظ بالإعدادات متناسقة عبر الخدمات حتى لا يصبح نقطة ضعف

تكلفة الأداء في واجهات خلفية حقيقية

مع تجزئة كلمات السر، "الأسرع أفضل" عادةً هدف خاطئ. تريد لكل تخمين أن يكون مكلفًا للمهاجمين بينما تظل تجربة تسجيل الدخول سلسة للمستخدمين الحقيقيين.

طريقة عملية هي تخصيص ميزانية زمنية لكل تحقق على أجهزة الإنتاج الفعلية. كثير من الفرق تستهدف شيء مثل 100 إلى 300 ملّ ث لكل فحص هاش، لكن الرقم الصحيح يعتمد على حركة المرور والخوادم لديك. الاختلاف بين bcrypt و Argon2 هو ما تنفقه: bcrypt في الغالب وقت CPU، بينما Argon2 يمكن أن يحجز ذاكرة أيضًا.

اختر زمنًا مستهدفًا ثم قِس

اختر زمن هدف للتحقق واختبر في ظروف تشبه الإنتاج. قِس كل من تجزئة التسجيل/تغيير كلمة السر والتحقق عند تسجيل الدخول، لكن اعتبر تسجيل الدخول مسارًا حارًا.

خطة قياس خفيفة الوزن:

• اختبر 1 و10 و50 تحقق متزامن وسجل زمن p50 وp95
• كرِّر التشغيلات لتقليل الضجيج من التخزين المؤقت ورفع تردد CPU
• قِس استدعاء قاعدة البيانات بشكل منفصل حتى تعرف تكلفة التجزئة الحقيقية
• اختبر باستخدام نفس الحاوية وقيود CPU التي ستنشر بها

الذروات أهم من المتوسطات

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

إذا استغرق التحقق 250 ملّ ث ويمكن لخادمك معالجة 40 تحققًا متزامنًا قبل الطوابير، فإن موجة 500 محاولة دخول تتحول إلى انتظار لثوانٍ. في هذا الموقف، تقليل طفيف في التكلفة مع حدود معدل قوية قد يحسِّن الأمان الحقيقي أكثر من دفع المعلمات إلى حد يجعل نقطة الدخول هشة.

حافظ على توقُّع تسجيل الدخول التفاعلي

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

كيفية اختيار المعلمات خطوة بخطوة

ضبط المعلمات يعني رفع تكلفة المهاجم لكل تخمين دون إبطاء تسجيل الدخول أو زعزعة استقرار الخوادم.

1. اختر خوارزمية تدعمها بنيتك جيدًا. إذا كان Argon2id متاحًا ومدعومًا جيدًا، فهو عادة الخيار الافتراضي. إن لم يكن، bcrypt مقبول.

2. حدد زمنًا مستهدفًا لكل هاش على أجهزة تشبه الإنتاج. اختر شيئًا يحافظ على سلاسة تسجيل الدخول خلال الذروة.

3. اضبط ليطابق ذلك الزمن. مع bcrypt غيّر عامل التكلفة. مع Argon2id،وازن بين الذاكرة، التكرارات، والتوازي. الذاكرة هي الرافعة التي تغيّر اقتصاديات المهاجم أكثر.

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

5. خطط للترقيات باستخدام إعادة التجزئة عند تسجيل الدخول. عندما يسجل المستخدم الدخول، إذا كان الهاش المخزن أضعف من سياسة اليوم، أعد تجزئته واستبدله.

نقطة انطلاق عملية

إن احتجت لخط أساس قبل القياس، ابدأ بشكل محافظ وعدّل حسب التوقيت.

• بالنسبة لـ bcrypt، يبدأ كثير من الفرق حول عامل 12 ويتحركون بناءً على القياسات الحقيقية.
• بالنسبة لـ Argon2id، خط أساسي شائع هو ذاكرة بعشرات إلى مئات الميغابايت، تكلفة زمن 2 إلى 4، وتوازي 1 إلى 2.

عامل هذه كمواقع بداية لا قواعد صارمة. الإعداد الصحيح هو الذي يناسب حركة المرور والعتاد وانفجارات تسجيل الدخول لديك.

أخطاء شائعة تضعف التخزين

معظم إخفاقات تخزين كلمات السر تأتي من ثغرات الإعداد، لا من خوارزمية مكسورة.

أخطاء الـ salt شائعة. كل كلمة سر تحتاج salt فريد مخزن مع الهاش. إعادة استخدام salts أو استخدام salt عام يجعل مهمة المهاجم أسهل.

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

الضبط المفرط لـ Argon2 سبب شائع آخر. وضع ذاكرة عالية جدًا قد يبدو جيدًا نظريًا، ثم يسبب تسجيلات دخول بطيئة أو طوابير أو أخطاء نفاد الذاكرة أثناء الذروة.

التعامل مع طول كلمة السر مهم، خصوصًا مع سلوك bcrypt حول 72 بايت. إذا سمحت بكلمات سر طويلة واقتطعتها صامتًا، فأنت تخلق سلوكًا مربكًا وتضعف الأمان.

بعض العادات العملية تمنع معظم المشاكل:

• استخدم salts فريدة لكل كلمة سر (دع المكتبة تولدها)
• نفذ اختبارات تحميل وأعد ضبط الإعدادات بشكل دوري
• اضبط ذاكرة Argon2 بالنسبة لحركة الذروة، لا لاختبار طلب واحد
• اجعل حدود طول كلمة السر صريحة ومتسقة
• ضع حدود تزامن ومراقبة على نقطة الدخول

قائمة تدقيق سريعة لإعداد أكثر أمانًا

احتفظ بهذه القائمة القصيرة عند الإطلاق وعند تغيير البنية:

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

فحص سهل: شغّل اختبارًا في بيئة ستاجينج يتضمن موجة تسجيلات دخول (ناجحة وفاشلة) وراقب زمن الطرف إلى الطرف وCPU وRAM. إن عانى مسار تسجيل الدخول، اضبط التكلفة وشد حدود المعدل. لا "تصلح" المشكلة عبر قطع أساسيات مثل الـ salts.

مثال واقعي: الضبط لتطبيق ويب صغير

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

تختار Argon2id لرفع تكلفة الكسر في وضع عدم الاتصال. اختر زمن تحقق مستهدف على العتاد الحقيقي للخادم (مثلاً 100 إلى 250 ملّ ث)، ثم اضبط المعلمات للوصول إليه مع مراقبة RAM، لأن إعدادات الذاكرة يمكن أن تحد من عدد تسجيلات الدخول المتزامنة.

حلقة الضبط العملية تبدو هكذا:

• ابدأ بتكرارات وتوازي متواضعين
• زد الذاكرة حتى يصبح التزامن مزعجًا
• عدّل التكرارات لمزج زمن التجزئة
• اختبر مجددًا مع موجات محاكاة، لا فقط طلبات فردية

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

بعد الاصدار، راقب تسجيل الدخول مثل أي نقطة حرجة: ذيول الزمن (p95/p99)، استخدام CPU وRAM أثناء الذروات، قفزات في المحاولات الفاشلة، ومدى سرعة استبدال الهاشات القديمة.

الخطوات التالية: أطلق بأمان واستمر بالتحسين

اكتب سياساتك واعتبرها إعدادًا حيًا. على سبيل المثال: "Argon2id مع X ذاكرة، Y تكرارات، Z توازي" أو "bcrypt عامل تكلفة N"، مع تاريخ الاختيار وموعد مراجعته (كل 6–12 شهرًا مناسب).

احفظ مسار ترقية حتى لا تعلق بإعدادات قديمة. إعادة التجزئة عند تسجيل الدخول بسيطة وتعمل جيدًا في معظم الأنظمة.

الهاش القوي يساعد، لكنه لا يغني عن ضوابط مضادة للإساءة عبر الإنترنت. حدود المعدل، الإقفال، وتدفقات إعادة التعيين الحذِرة مهمة بنفس قدر أهمية التجزئة في الأمان الواقعي.

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