سؤال

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

ما هي أفضل الممارسات التي يجب وضعها في الاعتبار عند تصميم صفحة تسجيل الدخول؟

بعض الأسئلة التي ظهرت حول هذه المسألة:

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

المحلول

ملاحظات قابلية الاستخدام:

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

والأفضل من ذلك ، أيضًا التقاط Keypress Enter على حقل كلمة المرور حتى أتمكن من تقديم تلقائي باستخدام مفتاح Enter.

نصائح أخرى

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

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

على الجانب الفني ، ينجز Bank of America هذا باستخدام كائن مشترك محلي Flash يسمى Passmark. يرسل متصفحك بصمت هذه البيانات التي تحدد نفسك إلى البنك. إذا قمت بحذف LSO ، فلن يتم عرض صورتك لأن BOFA لا يمكن أن تعرفك. حتى هذا لا يزال عرضة للهجمات الرجل في الوسط.

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

المجلة Smashing لديها جولة كاملة حول نماذج تسجيل الدخول.أنماط تصميم نموذج الويب: أشكال التسجيل

تشمل منع مستوى التطبيق DOS

كن غير محدد مع فشل تسجيل الدخول. عام "فشل تسجيل الدخول" بدلاً من "اسم المستخدم غير المعروف".

استخدم captcha أو اختبار تورينج آخر.

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

وأنا أتفق مع Omniwombat. يعد التصيد مشكلة صعبة لحلها بشكل جيد ويبدو أنه من المستحيل حلها تمامًا.

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

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

فكر في استخدام NTLM أو OpenID أو Shibboleth لجعل تسجيل الدخول تلقائيًا قدر الإمكان لمعظم المستخدمين.

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

نصيحة مفيدة للظروف القادمة: يمكنك تعطيل حفظ كلمة المرور من جانب العميل عن طريق إضافة الإكمال التلقائي = "OFF" إلى حقل كلمة المرور.

هذا لا يعمل على جميع المتصفحات (إذا كنت أتذكر ، أي 6+ و Firefox 3+)

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

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

Joe Lencioni ، وكل شخص آخر مهتم بـ Shibboleth

يجب أن يكون لصفحات موقعك نفس المظهر والمظهر العام في كل صفحة.

بخصوص شيببوليث ، و SSO. من المهم ملاحظة الدور الذي ترتبط به مؤسستك. هل أنت مزود هوية - IDP (مصادقة المستخدم ثم إرسال الاستجابة إلى SP) ، أو هل أنت مزود الخدمة - SP (الذي سيمنح المصادقة بناءً على الاستجابة والسمات التي يتم إرسالها بواسطة IDP.

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

إذا كنت IDP ، فيجب أن يكون لديك صفحة تسجيل دخول تبدو مألوفة للمستخدم حتى يتمكنوا من تسجيل الدخول ثم إعادة توجيهها إلى SP مع السمات المطلوبة لـ SP لمنح الوصول المناسب.

بقدر ما تذهب عمليات الاحتيال الخادقة ، من المهم الحفاظ على تيار البيانات الوصفية Shibboleth. أعتقد أن العديد من الاتحادات توصي بتنزيل البيانات الوصفية كل (1) ساعة.

يمكن الإجابة على العديد من أسئلة Shibboleth هنا: https://spaces.internet2.edu/display/shib2/home

آمل ان يساعدك هذا.

مرخصة بموجب: CC-BY-SA مع الإسناد
لا تنتمي إلى StackOverflow
scroll top