تجزئة/التمليج من جانب العميل عبر https

Question

أتساءل ما هي المشكلات الخطيرة مع الإعداد التالي:

يطلب مخطط تسجيل الدخول إلى اسم المستخدم/كلمة المرور JavaScript/Ajax قيمة الملح من الخادم (لقد أنشأنا في الأسئلة السابقة أن الملح ليس قيمة سرية) JavaScript يقوم بتشكيل SHA1 (أو غير ذلك) من كلمة المرور والملح. javaScript/Ajax قم بإرجاع التجزئة إلى الخادم ، ويطبق الخادم الملح/التجزئة الأخرى على الجزء العلوي من المرسلة عبر Ajax.

المعاملات أكثر من https.

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

Answer 1

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

Answer 2

كما هو الحال دائمًا: كن حذرًا جدًا في تصميم بروتوكولات التشفير بنفسك.

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

قد ترغب في القراءة من خلال RFC 2617 حول HTTP Digest Access المصادقة. هذا المخطط مشابه لما تقترحه.

Answer 3

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

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

Answer 4

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

إذا كنت ترغب حقًا في زيادة الأمن ، فاستخدم التجزئة المستندة إلى SHA-2 (SHA-224/256/384/512) ، لأن SHA-1 لديه نقاط ضعف محتملة. لم يعد NIST يوصي SHA-1 بالتطبيقات المعرضة لهجمات التصادم (مثل تجزئة كلمة المرور).

Answer 5

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

سببان... . يجب ألا يعتمد العميل على أن جميع مكونات الخادم والشبكات الداخلية هي TSL. من الشائع جدًا أن تكون نقطة نهاية TSL بمثابة وكيل عكسي موازنة التحميل ، والذي يتواصل مع خوادم التطبيق باستخدام النص العادي لأن DevOps لا يمكن أن يزعجنا إنشاء خوادم Certs لجميع خوادمها الداخلية.

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