كم تكلّف كلمة المرور على عتاد متواضع

يمكن حماية صفحات الإحصائيات هنا بكلمة مرور. وحساب التجزئة (hash) لكلمة المرور هذه هو العملية الوحيدة في هذه الخدمة التي يُفترض أن تكون بطيئة — فهذا ما يجعل مهاجمة تجزئة مسروقة أمرًا مكلفًا. والسؤال هو: ما مدى البطء على هذا العتاد؟

القياس على الجهاز الذي يشغّل هذا الموقع، PHP 8:

PASSWORD_DEFAULT	560 ms	(يعادل cost 12)
cost 12	595 ms
cost 11	277 ms
cost 10	138 ms

معامل الكلفة (cost) في bcrypt أُسّ: كل درجة تضاعف العمل. وتُظهر القياسات هذا التضاعف بالضبط، وهي علامة جيدة على أن لا شيء آخر يتدخل في النتيجة.

لماذا القيمة الافتراضية اختيار خاطئ هنا

رفعت PHP الكلفة الافتراضية لـ bcrypt من 10 إلى 12. على خادم بقدرات حاسوب مكتبي تُعد هذه ترقية معقولة — فهي بضع عشرات من المللي ثانية. أما على عتاد متواضع فهي أكثر من نصف ثانية من وقت المعالج الخالص، على جهاز يرسم في الوقت نفسه صور العدادات لجميع المستخدمين الآخرين.

نصف ثانية لكل تسجيل دخول أمر سيئ في حد ذاته. والأسوأ أنه دعوة مفتوحة: يستطيع أي شخص استدعاء نقطة نهاية تسجيل الدخول، وكل استدعاء يستهلك 560 ms من وقت المعالج الذي يخدم الموقع كله. وهذا يحوّل التحقق من كلمة المرور إلى أرخص منفذ متاح لهجوم حجب الخدمة.

لذلك ثُبّتت الكلفة على 10 بدلًا من تركها للقيمة الافتراضية. وهذا أضعف عمدًا مما تختاره PHP الآن، وينبغي قول ذلك بوضوح لا إخفاؤه: مهاجمة تجزئة بكلفة 10 أرخص بأربع مرات من مهاجمة تجزئة بكلفة 12. وما يعوّض ذلك هو ما تحميه كلمة المرور فعلًا — إمكانية رؤية صفحة فيها أعداد الزيارات، لا حساب، ولا مال، ولا هوية. لا يوجد خلفها شيء يمكن الاستيلاء عليه.

الجزء الذي يسهل أن يفوتك

PASSWORD_DEFAULT قيمة متحركة بحكم التصميم. فالكود الذي كُتب قبل سنوات ويستخدمها سيصبح أبطأ بصمت مع كل ترقية لـ PHP — الشيفرة المصدرية نفسها، والمدخلات نفسها، وزمن تشغيل أطول بعدة أضعاف. هذا هو السلوك المقصود، وهو صحيح لمعظم البرمجيات.

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