Yeah, I agree that aspect of it seemed quite problematic to me as well from the beginning. And he obviously cannot include the email in the hash. So it’s better to just disallow the top x most common passwords, which we already have. (Though it’s not updated on the fly as the list changes over time.)
إعجابَين (2)
What would really solve the issue here, in my humble opinion, would just to apply best practices like preventing an IP to try to login more than X times without success, don’t let people try passwords at non human time ( humans don’t try a password every 1 sec ) would fix the security issue without forbidding all the passwords.
The way I see is, someone can make a list that gives all the combinations of A-Z 1-9 up to X length. This means nothing if you can’t brute force the target, unless it’s a targed attack and then there’s not much you can do.
Is anything like that currently implemented?
Yes, there is extensive rate limiting across the whole of Discourse. By default login attempts are limited to 6 per minute and 30 per hour (per IP).
9 إعجابات
Hmm, can you extrapolate here though? It would seem to me that the distribution of lengths might be quite different if you focus on the 1 mil most common ones since those will obviously tend to be shorter.
إعجاب واحد (1)
I think it’s a good idea to alert the user but maybe not prevent them from using the password if they insist. Explain it better, maybe something along the lines of
“The encrypted version of this password has been found in a public database of stolen user information and may put your account at increased risk of being hacked by brute force attacks. If you use this password across multiple web services we strongly recommend changing them to unique passwords to stay secure, especially for mail accounts.”
And let them hit submit a second time to use it anyway.
hopefully webauthn will make passwords a thing of the past someday 
إعجابَين (2)
هذا غير منطقي بالنسبة لي (ومن هنا جاء رفع الموضوع)، فبمجرد أن يُعرف أن كلمة مرور قد تم كسرها (أو العثور عليها كنص واضح)، فإن أمانها ينخفض بشكل كبير. وهذا يمثل انخفاضًا هائلاً في الإنتروبيا حتى مع افتراضات متسامحة للغاية:
- كلمة مرور عشوائية مكونة من 10 أحرف، حتى مع مجموعة أحرف محدودة للغاية (مثال افتراضي لأحرف صغيرة فقط: Pr = 1/26^10 = 1/1.4e14)
- كلمة مرور يُعرف أنها موجودة في قائمة HIBP (Pr = 1/5e8)
في اللحظة التي يستخدمها شخص آخر وتم اختراقها و/أو فك تشفيرها أيضًا - هذا هو الفرق الجوهري.
ما هي المشكلة العملية في منع كلمة مرور ظهرت في قائمة واحدة فقط؟ ك مستخدم، من المؤكد أنني أود معرفة ذلك لتجنب استخدام هذه الكلمة مرة أخرى. وكأدمن لموقع، لا أريد أن يستخدم مستخدمو كلمات مرور مخترقة. يبدو أن هذا يستحق مقايضة قابلية الاستخدام هذه.
لا، هذا ليس فرقًا جوهريًا، لأن جميع كلمات المرور ستُختَرق إحصائيًا مع مرور الوقت.
تذكّر أننا نمنع بالفعل أكثر مليون كلمة مرور شيوعًا منذ سنوات، لذا فأنت محمي بالفعل بالطرق التي تهم.
3 إعجابات
إحصائيًا، ستُكسَر جميع خوارزميات التشفير والتجزئة مع مرور الوقت. وعند ظهور أول مؤشر على أن خوارزمية ما على وشك الكسر نتوقف عن استخدامها.
لماذا يجب أن تكون كلمات المرور مختلفة؟ فكل أمن هو رهان بأن الإنتروبيا المستخدمة كافية للمهمة المعطاة، وهناك دائمًا افتراض بشأن طول أو كثافة الهجوم الذي يمكن تحمّله.
وبالنظر إلى أنك تفقد على الأقل ستة رتب من الإنتروبيا في المرة الأولى التي تظهر فيها كلمة المرور في قائمة (وواقعياً ربما أكثر من ذلك بكثير)، يبدو هذا قرارًا سهلاً.
نعم، هذا وضع أفضل بكثير مما هو موجود في العديد من حزم البرامج المتاحة اليوم. لا يزال موقع HIBP تحسينًا جيدًا للمواقع التي ترغب في ضمانات إضافية فوق ذلك.
يبدو أن هناك فرصة لإضافة زر “توليد عبارة مرور” عبر إضافة، إذا كان ذلك ممكنًا تقنيًا…
سيستبعد هذا الزر أي كلمة موجودة في قائمة المخترقة، ويمكن للمستخدم اختيار إنشاء عبارة مرور خاصة به، والتي تتضمن بالفعل قائمة استبعاد أساسية تضم مليون مدخل. أما طريقة الزر فتعني أنه يمكن تخطي الحاجة إلى تثقيف المستخدم حول القوائم المخترقة والإنتروبيا، وهو ما عادةً لن يكون لديه وقت له.
ومع ذلك، أعتقد أن منصة Discourse تقوم بعمل جيد بما يكفي بالفعل.
لماذا يتم توليد كلمة المرور على الخادم؟
بافتراض أن المستخدم يحتاج إلى حفظها، ألا يكون من المنطقي أن يتحمل المستخدم مسؤولية توليد كلمة المرور؟ فمن المرجح أن مدير كلمات المرور الذي يختاره يقوم بذلك بالفعل.
إعجابَين (2)
لأنه قد يكون أفضل من إخبارهم باستمرار أن كلمات المرور مثل “apple”، “apple1”، “apple 123”، “apple 12345” غير مقبولة ضمن قائمة الممنوعات التي تتجاوز المليون. شخصيًا، لا أتوقع وجود هذه الميزة في Discourse، لكن إذا ساعدت في التعامل مع مشكلة كلمات المرور المخترقة بطريقة لائقة تترك للمستخدم الخيار في حال حدوث خطأ، فقد تستحق النظر فيها.
وهل تقترح أن مديري كلمات المرور من جانب العميل سيقومون بتوليد كلمات مرور مثل هذه؟
إن الدعوة إلى استخدام مستخدميك لمدير كلمات مرور ستكون أكثر فعالية من فرض كلمة مرور من موقع واحد. فالأخير سيؤدي فقط إلى استخدامهم لتلك الكلمة في كل مكان آخر، مما يسرع من اختراقها.
إصلاح الغباء أصعب من إصلاح ما تم اختراقه؛ والتعاون مع شيء يشبه https://www.useapassphrase.com/ يمنح أولئك الذين لا يهتمون بالجوانب الأكاديمية له شيئًا مفيدًا، في رأيي.
لقد بنيت أنظمة يستخدمها عشرات الملايين، وقد اختبرنا نهجًا مختلفة تتعلق بكلمات المرور، بما في ذلك تلك المزعجة التي تشترط احتواءها على حرف x وحرف y.
ما لم تُعلّم المستخدمين إدارة كلمات المرور، فإنك تزيد فقط من احتمالية إجهاد كلمات المرور، وإعادة استخدامها، والمشكلة المزعجة المتمثلة في “مذكرة لاصقة تحت لوحة المفاتيح”.
كما أن توليد كلمات المرور على الخادم يخلق أيضًا نقطة هجوم جديدة وسطحًا يحتاج إلى تأمين. شخصيًا، أستغني عن كل ما سبق.
3 إعجابات
كنت لأتوقع أن يقوم JavaScript بتوليد عبارة مرور عشوائيًا من جانب العميل، ثم يقوم بتجزئتها ومقارنتها بقائمة. يمكن أن يكون الجزء التعليمي مجرد عنصر نائب فوق زر “أنشئ لي كلمة مرور”. بصراحة، لا أعتقد أن أيًا من هذا شيء يحتاج Discourse للانشغال به، لكن طالما أن الناس يعزون غضبهم لسلوكياتهم الخاصة إلى العلامة التجارية، فقد يكون من الجدير النظر في الأمر.
أعتقد أن أفضل خيار لديك، إذن، هو تطوير أو تكليف إضافة تقوم بما تقترحه.
إعجاب واحد (1)
هذا هو بالضبط الغرض من هذه الإضافة.
لقد فكرت في هذا الأمر لبعض الوقت منذ كتابة هذه الإضافة، وقد توصلت إلى الاتفاق مع جيف.
كلمة “تم اختراقها” تعني أن هناك شخصًا ما، في مكان ما، ابتكر هذه العبارة التي ظهرت على “قائمة ما”. تخيل لو أن شخصًا ما أنشأ أداة تقوم بـ:
- جعل قائمة من السلاسل النصية متاحة للعامة.
- توليد سلاسل نصية فريدة وإضافتها إلى القائمة بشكل منهجي.
حجة جيف هي أن هذا يعني أنه مع مرور الوقت، ستكون جميع السلاسل النصية “غير آمنة” لأنها ستظهر على قائمة عامة ما في مكان ما - وفي النهاية، ستظهر عبارة المرور “الفائقة الأمان” الخاصة بك أيضًا على هذه القائمة المتوسعة باستمرار.
الفكرة الكاملة لكلمات المرور نفسها تعتمد فقط على “الاستحالة الإحصائية” لعدم قدرة شخص ما على تخمين كلمة مرور لحسابك. تقنيًا، لا يحتاج المهاجم إلى معرفة كلمة المرور؛ بل يحتاج فقط إلى تقديم تخمين جيد جدًا. يمكنه تعزيز فرصه من خلال فهم ما يعنيه تقديم “تخمين جيد”:
- إذا كان لديهم خرق، جرب نفس كلمة المرور لنفس الحساب.
- إذا كان لديهم قائمة بالخرق، جرب كلمات المرور التي يستخدمها الكثير من الناس.
لقد ناقشنا بالفعل كيف أن ديسكورش جيد في البند رقم 2 أعلاه. أعتقد أن ما تحاول استهدافه هو البند رقم 1، لكنه غير ضروري إلى حد كبير ويُسبب كابوسًا من حيث سهولة الاستخدام أن يكون لديك شيء مثل هذا (بافتراض أنه لا ينبغي استخدام أي كلمة مرور غير مرتبطة باسم المستخدم) في النواة… ولكن إذا كنت تريد ما تصفه لموقعك، فإن هذه هي الإضافة المناسبة لك.
4 إعجابات
نعم. بصراحة، هذه حجة سيئة لأنها منفصلة تمامًا عن أي مفهوم للاحتمالية، وهو الطريقة الوحيدة الصحيحة للاستدلال في هذا الشأن.
لحسن الحظ، نحن نتحدث عن حالة هامشية تظهر بعد استبعاد أكثر كلمات المرور شيوعًا، وهي بالفعل استراتيجية جيدة بحد ذاتها.
إعجاب واحد (1)