security - أين تخزن سلاسل الملح؟




authentication hash cryptography salt (5)

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

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

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

هل هناك أي حلول موصى بها لهذا؟


Answers

في كثير من الأحيان ، يتم إلحاقها مسبقا إلى التجزئة وتخزينها في نفس المجال.

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

إذا كان لديك موقع تخزين أكثر أمانًا ، فمن المنطقي تخزين التجزئة فقط.


سوف أعرض على اتخاذ مختلف قليلا في هذا الشأن.

أنا دائما تخزين الملح مختلطة مع تجزئة كلمة المرور المملحة.

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

مبرراتي لهذا النهج:

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

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

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

الاستنتاج لهذا ..

1) لا تخزن مطلقًا البيانات التي يستخدمها تطبيق المصادقة في شكله الدقيق.

2) إذا كان ذلك ممكنا ، والحفاظ على سرية منطق المصادقة للحصول على مزيد من الأمان.

اذهب خطوة واحدة أخرى ..

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

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

على سبيل المثال ، يمكنك إنشاء ملح عشوائي من 512 بايت. يمكنك إلحاق الملح بكلمة المرور الخاصة بك ، والحصول على التجزئة SHA-512 من كلمة المرور المملحة الخاصة بك. يمكنك أيضًا إنشاء عدد صحيح عشوائي 200. ثم تقوم بتخزين أول 200 بايت من الملح ، متبوعة بتجزئة كلمة المرور المملحة ، متبوعة بما تبقى من الملح.

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

الايجابيات من هذا النهج:

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

سلبيات هذا النهج:

حيث يتم الاستدلال على المنطق الدقيق في وقت التشغيل ، يكون هذا الأسلوب كثيفًا جدًا CPU. كلما طال طول الملح ، كلما ازداد استخدام هذا المعالج.

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

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


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

لا توجد نقطة حقيقية في تخزين الأملاح في ملف منفصل طالما كانت على أساس كل مستخدم - حيث أن نقطة الملح هي ببساطة لجعله بحيث لا يمكن لطاولة قوس قزح أن تكسر كل كلمة مرور في DB.


استنادا إلى تطوير تطبيقات الويب ASP.NET MVC 4 كتاب ويليام Penberthy:

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

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





security authentication hash cryptography salt