كيف يمكنني أخلاقيا النهج المستخدم تخزين كلمة المرور في وقت لاحق عادي استرجاع ؟

https://stackoverflow.com/questions/2283937

21-09-2019
|

سؤال

كما تواصل بناء المزيد والمزيد من المواقع و تطبيقات الويب إنني كثيرا ما يطلب لتخزين المستخدم وكلمات السر في الطريقة التي يمكن استرجاعها إذا/عندما يقوم المستخدم لديه مشكلة (إما أن البريد الإلكتروني و كلمة المرور المنسية الرابط, المشي من خلال عبر الهاتف ، إلخ.) عند قتال مرير ضد هذه الممارسة أفعل الكثير من 'إضافية' البرمجة لجعل إعادة تعيين كلمة المرور و المساعدة الإدارية ممكنا من دون تخزين كلمة المرور الفعلية.

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

في عالم مثالي الناس أن تحديث كلمات المرور بشكل متكرر و غير مكررة لهم عبر العديد من المواقع المختلفة—للأسف أنا أعرف الكثير من الناس التي لها نفس العمل/المنزل/البريد الإلكتروني/كلمة المرور البنك ، بل بحرية تعطى لي عندما يحتاجون إلى المساعدة.أنا لا أريد أن أكون مسؤولة عن المالية زوال إذا DB الإجراءات الأمنية تفشل لسبب ما.

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

معلومات إضافية عن فضله

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

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

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

شكرا للجميع

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

كما هو الحال دائما هناك حوالي 5 إجابات أود أن يكون وضع علامة الصحيح لأسباب مختلفة ، ولكن اضطررت إلى اختيار أفضل واحد--كل ما تبقى حصلت على +1.شكرا للجميع!

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

المحلول

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

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

تتمثل إحدى هذه المشكلة في توفير كلمات مرور تم إنشاؤها تلقائيًا والتي تكون نصًا طبيعيًا إلى حد ما. على الرغم من أن سلاسل اللغة الطبيعية قد لا تحتوي على إنتروبيا أن سلسلة من الأحرف العشوائية من نفس الطول ، لا يوجد شيء يقول أن كلمة المرور التي تم إنشاؤها تلقائيًا تحتاج إلى 8 (أو 10 أو 12) فقط. احصل على عبارة تمارين تم إنشاؤها تلقائيًا عالياً عن طريق ربط العديد من الكلمات العشوائية معًا (اترك مساحة بينهما ، لذلك لا تزال قابلة للمعروفة ومكتوبة من قبل أي شخص يمكنه القراءة). من المحتمل أن تكون الستة كلمات عشوائية ذات طول متفاوت أسهل في الكتابة بشكل صحيح وبثقة من 10 أحرف عشوائية ، ويمكن أن يكون لها إنتروبيا أعلى أيضًا. على سبيل المثال ، فإن إنتروبيا كلمة مرور 10 حرف يتم رسمها بشكل عشوائي من الأحرف الكبيرة والصغيرة والأرقام و 10 رموز علامات الترقيم (لما مجموعه 72 رمزًا صالحًا) سيكون لها إنتروبيا 61.7 بت. باستخدام قاموس من 7776 كلمة (كما يستخدم Diceware) والتي يمكن تحديدها بشكل عشوائي في عبارة الممر المكون من ستة كلمات ، سيكون لدى عبارة Passphrase إنتروبيا من 77.4 بت. انظر أسئلة وأجوبة في النرد لمزيد من المعلومات.

عبارة مرور مع حوالي 77 بت من الانتروبيا:
كلمة مرور بها حوالي 74 بت من الإنتروبيا: "k: & $ r^tt ~ qkd"

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

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

نصائح أخرى

تخيل أن شخصًا ما قد كلف مبنى كبير ليتم بناؤه - شريط ، دعنا نقول - ويتم المحادثة التالية:

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

هل يسأل المهندس المعماري بعد ذلك كيفية بناء هذا المبنى أخلاقياً بدون حريق يخرج؟

في صناعة البناء والهندسة ، من المرجح أن تنتهي المحادثة مثل هذا:

الهندسه المعماريه: لا يمكن بناء هذا المبنى بدون خروج النار. يمكنك الذهاب إلى أي محترف آخر مرخص وسيخبرك بنفس الشيء. انا راحل الان؛ اتصل بي مرة أخرى عندما تكون مستعدًا للتعاون.

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

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

لا توجد طريقة أخلاقية أو مسؤولة لتخزين كلمات المرور في شكل قابل للاسترداد. فترة.

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

أعتقد أن هذا في الواقع يشبه الطريقة وكيل استرداد Windows يعمل.

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

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

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

إذا كان لدى عملاؤك مشكلة في ذلك ، فأخبرهم أن تخزين كلمات المرور بشكل مستار يكون ضد القانون. هنا في المملكة المتحدة على أي حال ، يتطلب قانون حماية البيانات لعام 1998 (على وجه الخصوص ، الجدول 1 ، الجزء الثاني ، الفقرة 9) وحدات التحكم في البيانات لاستخدام التدابير الفنية المناسبة للحفاظ على آمنة البيانات الشخصية ، مع مراعاة ، من بين أمور أخرى ، الضرر الذي قد يحدث إذا تم اختراق البيانات - والتي قد تكون كبيرة للمستخدمين الذين يشاركون كلمات المرور بين المواقع. إذا كانوا لا يزالون يواجهون صعوبة في مطاردة حقيقة أنها مشكلة ، فقم بإشارةهم إلى بعض الأمثلة في العالم الحقيقي ، مثل هذا.

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

فيما يلي بعض منشورات المدونة التي كتبتها حول هذا الموضوع:

تحديث: لقد بدأنا الآن في رؤية الدعاوى القضائية والمحاكمات ضد الشركات التي تفشل في تأمين كلمات مرور المستخدمين بشكل صحيح. مثال: صفع LinkedIn مع دعوى قضائية جماعية بقيمة 5 ملايين دولار; تغريم سوني 250،000 جنيه إسترليني على اختراق بيانات PlayStation. إذا كنت أتذكر بشكل صحيح ، فإن LinkedIn كان يقوم بالفعل بتشفير كلمات مرور مستخدميها ، لكن التشفير الذي كان يستخدمه كان ضعيفًا جدًا بحيث لا يكون فعالًا.

بعد قراءة هذا الجزء:

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

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

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

ثم يتم إعداد النظام لمعرفة متى حدثت إعادة تعيين كلمة المرور وعرض رسالة "هل ترغب في الاحتفاظ بكلمة المرور الجديدة أو اختيار رسالة جديدة".

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

التعليق على ما هو سيء في اقتراحي وسأقترح حلاً يقوم بالفعل بما تريده في البداية.

لقد كان Michael Brooks صريحًا حول CWE -257 - حقيقة أنه مهما كانت الطريقة التي تستخدمها ، لا يزال بإمكانك (المسؤول) استعادة كلمة المرور. إذن ماذا عن هذه الخيارات:

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

أعتقد أن 1. هو الخيار الأفضل ، لأنه يمكّنك من تعيين شخص ما داخل شركة العميل من الاحتفاظ بالمفتاح الخاص. تأكد من قيامهم بإنشاء المفتاح بأنفسهم ، وتخزينه بالتعليمات في آمنة وما إلى ذلك ، حتى يمكنك إضافة الأمان عن طريق اختيار تشفير وتوفير شخصيات معينة فقط من كلمة المرور إلى الطرف الثالث الداخلي حتى يتعين عليهم كسر كلمة المرور للتخمين هو - هي. تزويد هذه الأحرف بالمستخدم ، ربما يتذكرون ما كان عليه!

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

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

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

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

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

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

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

عملاً بالتعليق الذي أدليت به على السؤال:
لقد تعرضت إحدى النقاط المهمة للغاية من قِبل الجميع تقريبًا ... كان رد فعلي الأولي مشابهًا جدًا لـ Michael Brooks ، حتى أدركت ، مثل Stefanw ، أن المشكلة هنا هي المتطلبات المكسورة ، لكن هذه هي ما هي عليه.
ولكن بعد ذلك ، حدث لي أن هذا قد لا يكون كذلك! النقطة المفقودة هنا ، هي غير المعلنة القيمة من أصول التطبيق. مجرد التحدث ، لنظام القيمة المنخفضة ، ستكون آلية مصادقة آمنة بالكامل ، مع كل العملية المعنية ، مبالغة ، و خاطئ اختيار الأمن.
من الواضح ، بالنسبة للبنك ، "أفضل الممارسات" أمر لا بد منه ، ولا توجد طريقة لانتهاك CWE-257 أخلاقيا. لكن من السهل التفكير في أنظمة القيمة المنخفضة حيث لا تستحق ذلك (ولكن لا تزال كلمة مرور بسيطة مطلوبة).

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

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

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

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

ومع ذلك ، فإن جوهر السؤال موجود المبدأ, هل هناك أي موقف قد لا يكون فيه ضروريًا لمنع هذا ، وإذا كان الأمر كذلك ، كيف تفعل ذلك في الطريقة الصحيحة المناسبة للوضع.

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

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

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

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

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

انتحال شخصية المستخدمين؟ لا ، لقد قبلت هذا الخطر بالفعل ، وليس مثيرًا للاهتمام.
مدير الشر؟ حسنًا ، ربما ... ولكن مرة أخرى ، لا يهمني إذا كان بإمكان شخص ما انتحال شخصية مستخدم آخر ، داخلي أو لا ... وعلى أي حال ، سيحصل مسؤول ضار على كلمة المرور الخاصة بك بغض النظر - إذا كان المسؤول الخاص بك سيئًا ، فإن لعبتها أكثر من أي حال.
قضية أخرى تم إثارة ، هي الهوية في الواقع مشاركة بين العديد من الأنظمة. آه! هذا خطر مثير للاهتمام للغاية ، يتطلب نظرة فاحصة.
اسمحوا لي أن أبدأ بتأكيد أنه ليس الفعلي هوية هذا مشترك ، بالأحرى دليل - إثبات, ، أو بيانات اعتماد المصادقة. حسنًا ، نظرًا لأن كلمة المرور المشتركة ستتيح لي فعليًا دخول نظام آخر (على سبيل المثال ، حسابي المصرفي ، أو Gmail) ، فهذا هو نفس الهوية فعليًا ، لذلك فهو مجرد دلالات ... باستثناء ذلك ليست كذلك. تتم إدارة الهوية بشكل منفصل من قبل كل نظام ، في هذا السيناريو (على الرغم من أنه قد يكون هناك أنظمة معرف الجهات الخارجية ، مثل OAUTH - لا يزال ، منفصلة عن الهوية في هذا النظام - أكثر في هذا لاحقًا).
على هذا النحو ، فإن النقطة الأساسية للمخاطر هنا ، هي أن المستخدم سوف يقوم بإدخال كلمة مروره (نفسه) عن طيب خاطر في عدة أنظمة مختلفة - والآن ، (المسؤول) أو أي هاكر آخر في موقعي سيتمكن من الوصول إلى كلمات مرور العمة Erma لـ موقع الصواريخ النووية.

أمم.

هل يبدو لك أي شيء هنا؟

أنه ينبغي.

لنبدأ بحقيقة أن حماية نظام الصواريخ النووية ليس مسؤوليتي, ، أنا فقط أقوم ببناء موقع نزهة عائلة Frakkin (لعائلتي). إذن من هي المسؤولية؟ أم ... ماذا عن نظام الصواريخ النووية؟ دوه.
ثانياً ، إذا كنت أرغب في سرقة كلمة مرور شخص ما (شخص معروف أنه يستخدم مرارًا وتكرارًا كلمة المرور نفسها بين المواقع الآمنة ، وغير الآمنة)-لماذا أزعج نفسي باختراق موقعك؟ أو تكافح مع تشفيرك المتماثل؟ goshdarnitall ، يمكنني فقط أن أطرح موقع الويب الخاص بي البسيط الخاص بي, ، اطلب من المستخدمين الاشتراك لتلقي أخبار مهمة جدًا حول ما يريدون ... Pupho Presto ، لقد سرقت كلمات المرور الخاصة بهم.

نعم ، تعليم المستخدم يعود دائمًا ليعضنا في Hienie ، أليس كذلك؟
ولا يوجد شيء يمكنك القيام به حيال ذلك ... حتى لو كنت تتواصل مع كلمات المرور الخاصة بهم على موقعك ، وفعل كل شيء آخر يمكن أن تفكر فيه TSA ، فقد أضفت الحماية إلى كلمة المرور الخاصة بهم لا واحد وايت, ، إذا كانوا سيستمرون في التمسك بكلمات مرورهم في كل موقع يصطدمون به. لا تهتم حتى المحاولة.

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

لذا ، فإن خبراء الأمن الأعزاء ، كسيدة عجوز كانت تطلب ويندي ، "أين المخاطرة؟"

نقاط قليلة أخرى ، ردا على بعض القضايا التي أثيرت أعلاه:

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

يا للعجب. يا له من منشور طويل ...
ولكن للإجابة على سؤالك الأصلي ، shane:

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

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

ماذا عن منزل منتصف الطريق؟

قم بتخزين كلمات المرور مع تشفير قوي ، ولا تمكّن إعادة التعيين.

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

يمكنك "بيع" هذا كآلية آمنة لإعادة ضبط كلمات المرور.

الطريقة الوحيدة للسماح للمستخدم باسترداد كلمة المرور الأصلية الخاصة بهم هي قم بتشفيره بمفتاح المستخدم الخاص بالمستخدم. يمكن لهذا المستخدم فقط فك تشفير كلمة المرور الخاصة بهم.

لذلك ستكون الخطوات:

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

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

أعتقد أن السؤال الحقيقي الذي يجب أن تطرحه على نفسك هو: "كيف يمكنني أن أكون أفضل في إقناع الناس؟"

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

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

تشفير مع: openssl_encrypt(سلسلة $ $ ، طريقة $ $ ، كلمة مرور السلسلة $)
- دليل PHP.
بيانات ARG:
- المعلومات الحساسة (مثل كلمة مرور المستخدم)
- التسلسل إذا لزم الأمر ، على سبيل المثال ، إذا كانت المعلومات عبارة عن مجموعة من البيانات مثل معلومات حساسة متعددة
كلمة المرور arg: استخدم معلومات يعرفها المستخدم فقط مثل:
- لوحة ترخيص المستخدم
- رقم الضمان الاجتماعي
- رقم هاتف المستخدم
- اسم أم المستخدم
- سلسلة عشوائية تم إرسالها عن طريق البريد الإلكتروني و/أو بواسطة الرسائل القصيرة في وقت التسجيل
طريقة arg:
- اختر طريقة تشفير واحدة ، مثل "AES-256-CBC"
مطلقا قم بتخزين المعلومات المستخدمة في وسيطة "كلمة المرور" في قاعدة البيانات (أو أي مكان في النظام)

عند الضرورة لإعادة محاكمة هذه البيانات ، ما عليك سوى استخدام وظيفة "OpenSSL_Decrypt ()" واطلب من المستخدم الإجابة. على سبيل المثال: "لتلقي كلمة المرور الخاصة بك أجب على السؤال: ما هو رقم هاتفك المحمول؟"

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

ملاحظة 2: للحصول على معلومات بطاقة الائتمان ، مثل "One Click Buying" ، ما أقوم به هو استخدام كلمة مرور تسجيل الدخول. تم تجزئة كلمة المرور هذه في قاعدة البيانات (SHA1 ، MD5 ، إلخ) ، ولكن في وقت تسجيل الدخول ، أقوم بتخزين كلمة مرور النص العادي في الجلسة أو في ملف تعريف الارتباط غير المتسق (أي في الذاكرة). لا تبقى كلمة المرور البسيطة هذه أبدًا في قاعدة البيانات ، بل إنها دائمًا ما تبقى في الذاكرة ، وتدميرها في نهاية القسم. عندما ينقر المستخدم على زر "One Click Buying" ، استخدم النظام كلمة المرور هذه. إذا تم تسجيل الدخول إلى المستخدم بخدمة مثل Facebook و Twitter وما إلى ذلك ، فأنا أطلب من كلمة المرور مرة أخرى في شراء الوقت (حسنًا ، إنها ليست بالكامل "على النقر") أو استخدم بعض بيانات الخدمة التي استخدمها المستخدم لتسجيل الدخول (مثل معرف Facebook).

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

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

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

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

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

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

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

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

لقد صادفت للتو هذه المناقشة المثيرة للاهتمام والساخنة. ما الذي فاجأني أكثر من غيره ، كم هو قليل من الاهتمام الذي تم إيلاءه للسؤال الأساسي التالي:

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

المعلومات التي يكون المستخدمون من كبار السن أو الشباب لا تجيب حقًا على هذا السؤال. ولكن كيف يمكن اتخاذ قرار العمل دون فهم مناسب للعميل؟

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

نظرًا لأنني لا أملك هذه المعلومات ولا يمكنني التحدث إلى هؤلاء العملاء ، لا يمكنني إلا أن أخمن: إنه يتعلق بالقدرة على الاستخدام ، انظر أعلاه.

سؤال آخر رأيته طرح:

س 2. إذا كان المستخدم لا يتذكر كلمة المرور في المقام الأول ، فلماذا تهم كلمة المرور القديمة؟

وهنا جواب ممكن. إذا كان لديك قطة تسمى "Miaumiau" واستخدمت اسمها ككلمة مرور ولكن نسيت أنك فعلت ، هل تفضل أن يتم تذكيرها بما كان يتم إرساله أو بالأحرى يتم إرسال شيء مثل "#zy*rw (EW"؟

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

أنا فقط أحاول فهم السبب. ولكن مهما كان السبب ، فهذا هو السبب ليس السبب الذي يجب معالجته.

كمستخدم ، أريد الأشياء بسيطة! لا أريد أن أعمل بجد!

إذا قمت بتسجيل الدخول إلى موقع إخباري لقراءة الصحف ، فأنا أريد الكتابة 1111 بكلمة مرور وأكون من خلال !!!

أعلم أن هذا غير آمن ولكن ماذا يهتم بالوصول إلى شخص ما إلى "حسابي"؟ نعم ، يمكنه قراءة الأخبار أيضًا!

هل يقوم الموقع بتخزين معلوماتي "الخاصة"؟ الأخبار التي قرأتها اليوم؟ ثم هذه هي مشكلة الموقع ، وليس لي! هل يعرض الموقع معلومات خاصة للمستخدم المصادق عليه؟ ثم لا تظهر ذلك في المقام الأول!

هذا فقط لإظهار موقف المستخدم من المشكلة.

لذا ، لتلخيص ، لا أشعر أنها مشكلة في كيفية "تخزين" كلمات مرور نص عادي (والتي نعرفها مستحيلة) ، ولكن كيفية معالجة الاهتمام الفعلي للعملاء.

معالجة كلمات المرور المفقودة/المنسية:

لا ينبغي لأحد أن يكون قادرًا على استعادة كلمات المرور.

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

تتحقق الصفحة وراء الرابط من وجود المعلمة GUID بالفعل (ربما مع بعض منطق المهلة) ، وتطلب من المستخدم كلمة مرور جديدة.

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

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

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

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

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

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

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

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

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

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

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

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

لذا أعتقد أن الجواب الحقيقي هو إذا كان أحد يريد أن يفعل الأشياء الصحيحة يستأجر الناس أنهم يمكن أن تثق بها, هل تحريات ممارسة الإدارة السليمة والرقابة والمساءلة.

ولكن بعد ذلك مرة أخرى إذا كان هذا المسكين عميل إدارة جيدة لما طلبوا هذا الأمن comprimised حل في المركز الأول, الآن أليس كذلك ؟

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

إذا لم تر أبدًا كلمة مرور النص العادي ، فلن تنشأ مسألة الاسترجاع.

أيضًا ، أجمع (من الويب) (يُزعم) أن بعض الخوارزميات مثل MD5 لم تعد آمنة. ليس لدي أي وسيلة للحكم على ذلك بنفسي ، لكن هذا شيء يجب مراعاته.

فتح ديسيبل على ملقم مستقل وإعطاء مشفر اتصال بعيد إلى كل ملقم ويب التي تتطلب هذه الميزة.
فإنه لا يجب أن يكون relational DB ، يمكن أن يكون نظام الملفات مع FTP access باستخدام المجلدات و الملفات بدلا من الجداول والصفوف.
تعطي ملقمات ويب الكتابة فقط الأذونات إذا كنت تستطيع.

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

الآن من أجل شخص ما للحصول على كلمة المرور و هو السياق (موقع معرف مستخدم + id + "لتمرير") ، لديه:

هاك الموقع DB للحصول على ("لتمرير" معرف المستخدم ) زوج أو أزواج.
الحصول على موقع معرف من بعض config
ابحث عن هاك في البعيد كلمات السر ديسيبل.

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

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

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

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

كما ذكرت في التعليقات ، لن ينجح هذا إذا تم اختراق البريد الإلكتروني ، لكنه يعالج تعليق Joachim حول عدم الرغبة في إعادة تعيين كلمة المرور. في النهاية ، سيتعين عليهم استخدام إعادة تعيين كلمة المرور ، لكن يمكنهم القيام بذلك في وقت أكثر ملاءمة ، أو بمساعدة مسؤول أو صديق ، حسب الحاجة.

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

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

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

في الأساس ، اجعل كلمة المرور المملحة/المملحة كلمة مرور "نص عادي".

مرخصة بموجب: CC-BY-SA مع الإسناد

لا تنتمي إلى StackOverflow