المشكلة مع كلمات السر

الكاتب لايال موليكان

ترجمة أحمد محمود

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

 

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

 

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

 

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

 

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

2. يمكن لكل من اسم المستخدم و كلمة السر أن تُستدعى من الذاكرة عند الحاجة.

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

 

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

 

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

 

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

 

تراه الآن، لا تراه الآن

 

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

 

من المفترض ان يكون شيئاً بسيطاً كتابة أداة تحكم للتبديل بين نوع الخاصية type attribute في عنصر الإدخال   في HTML أو HTML Input للتبديل بين خاصية كلمة السرpassword  و النص العادي text.

 

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

مكان التفاف الأسطر مميز بـ >>

 

 

 

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

 

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

 

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

 

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

 

بديل آخر

 

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

 

يمكننا ان نقوم باعادة إنتاج هذه الطريقة التدريجية لإخفاء كلمة السر ببعض من HTML و جافا اسكربت على الرغم من أنه سيأخد بضع سطور إضافية من الكود عن المثال السابق بأخذ الأتي  في الاعتبار:

 

 

أنشأنا هنا عنصر ادخال للنص Text Input ثانً يحل بشكل مباشر فوق كل عنصر إدخال لكلمة السر Password Input. (التحذير المتعلق  بالوراثة في CSS  من المثال السابق ينطبق هنا). يمكننا ان نتحكم فيما يراه المستخدم الآن عبر التحكم بقيمة هذا العنصر. لنفصّل كل خطوة في هذا الكود:

 

 

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

 

 

الآن إعطاء قيمة absolute لخاصية Position في عنصر الإدخال الجديد المدخل مباشرة قبل العنصر الأصلي ستجعله أعلى العناصر. يجب ـن يعمل هذا على معظم التخطيطات (التصميمات) و لكن يمكن أن يوجد بعض الاستثناءات التي تتطلب بعض المزيد من CSS  . بالطبع، نغطي الآن عنصر إدخال بآخر ولذا وجب التأكد من أن الضغط على العنصر المقنّع ينشط عنصر الإدخال و باضافة onFoucs ستتم بالمهمة بشكل جيد. فيما يتعلق بفايرفوكس 2 علينا تعيين هذه الميزة (onFocus) خاج عبارة with لتعمل بشكل جيد.

 

 

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

 

 

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

 

 

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

 

 

نريد الآن بعد ثانتين من التأخير أن نجعل كلمة السر المكتوبة مقنعة بالكامل ( يظهر نقاط او نجوم بدلا منها). مع ذلك لن يقف المستخدم لثانتين لكتابة الحرف التالي. ونريد نحن هذا السلوك عندما لا يحدث تغير في حقل كلمة السر لهذه الفترة الزمنية.  كل مرة نستدعي الدالة  setTimeout في الجافا سكربت سترجع معرفاً ID يمكن أن نستخدمة كمرجع لذلك المؤقت.

 

الآن عبر تخزين معرف المؤقت Timer ID في متغير وإضافة الكود في الأعلى إلى بداية دالتنا، يمكننا إلغاء هذا العد التنازلي في اللحظة التي نلاحظ فيها أن الحقل لايزال يتغير. 

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

 

لكي تري مثال للسكربت بالكامل ألقي نظرة على المثال الثاني  الذي تم اختباره في الانترنت اكسبلور 6 و 7 و الفايرفوكس و سفاري و كروم و طبعاً في غياب الجافا سكربت لن تعمل هذه الحيلة وسيتبع حقل  كلمة السر السلوك المألوف.

تابع بحذر

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

 

 

الرسوم: مايا زنقول

المقال الأصلي