أفضل طريقة للتعامل مع مصادقة حساب المستخدم وكلمات المرور

Question

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

أمثلة:

1. تخزين اسم المستخدم/كلمة المرور في قاعدة البيانات.هذه فكرة سيئة لأن أي شخص لديه حق الوصول إلى قاعدة البيانات يمكنه رؤية اسم المستخدم وكلمة المرور.وبالتالي استخدامه.

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

كيف يتعامل windows/*nix مع هذا؟

Answer 1

كانت هذه مشكلة شائعة في UNIX منذ سنوات عديدة، وتم حلها عن طريق فصل مكونات هوية المستخدم (اسم المستخدم، UID، الصدفة، الاسم الكامل، وما إلى ذلك) عن مكونات المصادقة (تجزئة كلمة المرور، ملح تجزئة كلمة المرور).يمكن أن تكون مكونات الهوية قابلة للقراءة عالميًا (وفي الواقع يجب أن تكون كذلك، إذا كان سيتم تعيين UIDs لأسماء المستخدمين)، ولكن مكونات المصادقة يجب تبقى غير قابلة للوصول للمستخدمين.لمصادقة مستخدم، يجب أن يكون لديك نظام موثوق به يقبل اسم المستخدم وكلمة المرور، وسيعرض نتيجة بسيطة "تمت المصادقة عليها" أو "لم تتم المصادقة عليها".يجب أن يكون هذا النظام هو التطبيق الوحيد الذي يمكنه الوصول إلى قاعدة بيانات المصادقة، ويجب أن ينتظر لفترة زمنية عشوائية (ربما بين 0.1 و3 ثوانٍ) قبل الرد للمساعدة في تجنب هجمات التوقيت.

Answer 2

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

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

Answer 3

سأختار 2 ولكن استخدم بعض الملح.بعض الكود الزائف:

SetPassword(user, password)
    salt = RandomString()
    hash = Hashfunction(salt+password)
    StoreInDatabase(user, salt, hash)

CheckPassword(user, password)
    (salt, hash) = GetFromDatabase(user)
    if Hashfunction(salt+password) == hash
        return "Success"
    else
        return "Login Failed"

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

@ بريان ر.بوندي:سبب استخدامك للملح هو جعل هجمات القاموس أكثر صعوبة، حيث لا يستطيع المهاجم تجزئة القاموس ومحاولة استخدام جميع كلمات المرور، وبدلاً من ذلك يتعين عليه أخذ الملح + القاموس وتجزئته، مما يؤدي إلى كشف متطلبات التخزين.إذا كان لديك قاموسًا لأكثر 1000 كلمة مرور شيوعًا وقمت بتجزئتها، فأنت بحاجة إلى شيء مثل 16 كيلو بايت، ولكن إذا أضفت حرفين عشوائيين، فستحصل على 62*62*16 كيلو بايت ≈ 62 ميجا بايت.

وإلا يمكنك استخدام نوع ما كلمات المرور لمرة واحدة لقد سمعت أشياء جيدة عن OTPW ولكني لم أستخدمها.

Answer 4

لدى Jeff Atwood بعض المشاركات الجيدة فيما يتعلق بالتجزئة، إذا قررت اتباع هذا الطريق:

• تكسير تجزئة قوس قزح
• من المحتمل أنك تقوم بتخزين كلمات المرور بشكل غير صحيح

Answer 5

يمكنك استخدام openID وعدم حفظ كلمات مرور المستخدم السرية على الإطلاق.ومن قال أنها للمواقع فقط؟

Answer 6

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

يقوم Unix بتخزين التجزئة في ملف نصي /etc/shadow، والذي لا يمكن الوصول إليه إلا للمستخدمين المميزين.يتم تشفير كلمات المرور بالملح.

Answer 7

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

Answer 8

الطريقة المعتادة هي استخدام الخيار الثاني مع البريد الإلكتروني:

قم بتخزين اسم المستخدم وتجزئة كلمة المرور وعنوان البريد الإلكتروني في قاعدة البيانات.

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

يحرر:إذا تم اختراق قاعدة البيانات، فيمكنك فقط ضمان عدم إمكانية الوصول إلى أي معلومات معقولة، ولم يعد بإمكانك ضمان أمان التطبيق الخاص بك.

Answer 9

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

Answer 10

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

Answer 11

إذا كان "النظام" موقعًا عامًا آر بي إكس يمكن أن يوفر لك خدمات تسجيل الدخول/حساب المستخدم لمقدمي الخدمة الأكثر شيوعًا، مثل OpenId وFacebook وGoogle وما إلى ذلك.

الآن، بالنظر إلى الطريقة التي صاغت بها سؤالك، أعتقد أن "النظام" الذي تتحدث عنه هو على الأرجح تطبيق مؤسسي داخلي يستند إلى Windows/Linux.مع ذلك؛بالنسبة لأولئك الذين يبحثون على Google عن موفري حسابات تسجيل الدخول/المستخدم (كما فعلت قبل أن أصادف RPX)، قد يكون هذا مناسبًا :)