مِلَدID يضيف وضعية البانك: ماذا يحدث عندما لا يمكن الاعتماد على الوصول إلى الحساب بعد الآن
ظهرت في مِلَدID آليات حماية جديدة لحالات غير عادية: تغيير كلمة المرور المؤجل، إنهاء عملية الاسترداد تلقائيًا بدون تطبيق الهاتف المحمول، ووضعية البانك التي تلغي الوصولات النشطة، وتقوم بحظر محاولات تغيير كلمة المرور غير المكتملة مع الحفاظ على بيانات المستخدم.
في المقالة السابقة عن مِلَدID كنت أكتب عن كيفية عمل النظام في الوضع الطبيعي: يخزن الملف التعريفي المدبر، يساعد على الدخول إلى الخدمات المتصلة، يزامن سجلات TOTP بين الأجهزة، ويسمح بتأكيد عمليات التفويض الجديدة عبر التطبيق المحمول.
لكن لدى أي نظام تعريف سيناريو غالبًا ما يُذكر بعد فوات الوقت: ماذا تفعل إذا لم يعد المستخدم يثق في حالة الوصول الحالية إلى حسابه؟
وللقيام بذلك، ليست هناك حاجة لمعرفة بالفعل أن الاختراق حدث. أحيانًا يكفي رسالة غير متوقعة حول استعادة كلمة المرور، جلسة غير معروفة، أو دخول من جهاز لا يتعرف عليه صاحب الحساب.
ولهذا الغرض، ظهرت في مِلَدID ميزتان جديدتان: تغيير كلمة المرور المؤجل ووضعية البانك.
أولاً، من المهم فهم كيف يتم إعداد كلمة مرور مِلَدID
في مِلَدID، المستخدم لا يختار كلمة المرور بنفسه، بل يُنشئها النظام تلقائيًا. هذا يسمح باستبعاد تركيبات ضعيفة وتنبؤية، إعادة استخدام كلمات مرور مألوفة، ومشاكل أخرى مرتبطة بالاختيار اليدوي.
وفي الوقت ذاته، لا يتم إرسال كلمة المرور الحالية إلى المستخدم عبر البريد الإلكتروني. صندوق البريد ليس مكانًا يمكن من خلاله الحصول على كلمة المرور الحالية لمِلَدID.
إجراء استعادة الحساب لا يكشف أيضًا عن كلمة المرور القديمة، بل يتيح فقط بدء عملية إنشاء كلمة مرور جديدة.
وبالتالي، فإن تعرُّض البريد الإلكتروني للخطر يشكل تهديدًا مختلفًا: الشخص الذي يحصل على الوصول إلى البريد قد لا يعرف كلمة مرور مِلَدID الحالية، لكنه يستطيع محاولة استخدام عملية الاستعادة وتعيين كلمة مرور جديدة.
هذا السيناريو هو أحد الأسباب التي دفعت إلى تعديل منطق الاستعادة نفسه.
كلمة المرور لم تعد تتغير فوريًا
في السيناريو المعتاد، العملية تحدث على الفور تقريبًا: يطلب المستخدم كلمة مرور جديدة، يتلقى رسالة ويتم إكمال العملية.
وهذا مريح طالما البريد الإلكتروني تحت السيطرة فقط. ولكن إذا حصل شخص آخر على الوصول إليه، فإن استعادة فورية تحول صندوق البريد إلى طريق مباشر لسيطرة على الحساب المرتبط.
في مِلَدID، طلب كلمة مرور جديدة يصبح بداية بتحذير، وليس استبدالًا فوريًا للكلمة القديمة. فالمستخدم يتلقى إشعارًا بمحاولة الاستعادة، ويبدأ بعدها فترة انتظار محددة.
مدة هذه الفترة يمكن أن تتغير، لكن المبدأ يبقى كما هو: هناك وقت بين الطلب وتفعيل كلمة المرور الجديدة للتحقق من الوضع.
وفي هذا الوقت، تظل كلمة المرور القديمة فعالة، لذا فإن مجرد بدء عملية الاستعادة لا يعني أن السيطرة على الحساب قد انتقلت إلى طرف آخر.
متى يكون التطبيق غير متاح
هناك سيناريو مهم يمكن أن يُغفل بسهولة: يمكن للمستخدم أن يستعيد كلمة المرور بنفسه، لكن دون الوصول إلى تطبيق مِلَدID، لأن الهاتف مفقود، أو معطل، أو مشحون، أو غير متاح مؤقتًا.
وفي هذه الحالة، تظل عملية الاستعادة ممكنة. بعد انتهاء فترة الانتظار، تُطبق كلمة المرور الجديدة تلقائيًا. التطبيق المحمول ليس شرطًا أساسيًا لإجراء الاستعادة التقليدي.
لذلك، إذا بدأ المستخدم عملية تغيير كلمة المرور وعجز عن فتح التطبيق، فلا يحتاج إلى بدء العملية من جديد، بل يكفي انتظار الانتهاء والدخول بكلمة المرور الجديدة.
أما إذا كان التطبيق متاحًا، فهناك خيارات أكثر: يمكن للمستخدم تفعيل كلمة المرور الجديدة على الفور أو إلغاء الطلب المشبوه. وإذا لم يكن هناك وصول للتطبيق، فإن الاستعادة المؤجلة تظل سارية.
المستخدم يقرر ما يفعل بعد ذلك
إذا قام مالك الحساب فعلاً بتشغيل الاستعادة ويملك التطبيق في يده، يمكنه فتح مِلَدID وتفعيل كلمة المرور الجديدة على الفور، بدون انتظار انتهاء فترة الانتظار.
أما إذا كانت الطلبية مفاجئة، يمكن إلغاؤها من التطبيق، والكلمة الجديدة لن تصبح فعالة، ويحافظ على القديمة.
هذا التغيير مهم في منطق الاستعادة ذاته. النظام لا يعتقد أن أي طلب هو صحيح تلقائيًا لمجرد أنه تم إطلاقه عبر البريد الإلكتروني. يترك لصاحب الحساب فرصة التدخل واتخاذ القرار من خلال جهاز مُوثوق.
تخيل الحالة العادية: يتلقى شخص ما إشعارًا بتغيير كلمة المرور، بدون أن يطلب ذلك بنفسه. يلغي العملية عبر التطبيق، ثم يتحقق من البريد، والأجهزة، ويبحث عن سبب النشاط المشبوه.
مِلَدID لا يمكنه استعادة السيطرة على البريد المخترق، لكنه قد يمنع الاختراق من توليد كلمة سر جديدة على الفور.
وضعية البانك تلغي الوصولات النشطة
تغيير كلمة المرور المؤجل يساعد في كسب الوقت، في حين أن وضعية البانك موجهة للمواقف التي يصبح فيها ذلك غير كاف، ويحتاج المستخدم إلى إيقاف الوصولات القديمة فورًا.
تتم من خلال تطبيق الهاتف بنقرة واحدة.
بعد التفعيل، تلغي النظام الرموز المفتاحية – مفاتيح الوصول، التي تحدد ما إذا كان المستخدم قد تم توثيقه، وتوقف الجلسات الموجودة على الهاتف، وسطح المكتب، والمواقع المرتبطة بالحساب.
يعني ذلك أن الجلسة الحالية على الهاتف تتوقف، وكذلك يتم إلغاء التوثيق عبر الأجهزة الأخرى التي دخلت سابقًا، مثل الحواسيب اللوحية، والمتصفحات، والتطبيقات المربوطة.
تعمل في مدة محددة، ويمكن تغيير مدتها، لكن المبدأ يظل أن الوصولات الحالية تتوقف، ويمنح المستخدم وقتًا للتحقق مما يحدث.
وضعية البانك لا تمحو البيانات
اسم الوضعية قد يبدو حادًا، لذلك من المهم توضيح ما لا يفعله.
وضعية البانك لا تمحو سجلات TOTP، الملف التعريفي المحفوظ، الإعدادات، أو بيانات المستخدم الأخرى. لا تُحذف محتويات الحساب، ولا يتحول إلى حساب فارغ.
التغيّر هو في حالة الوصول: يتم إلغاء الرموز المفتاحية الحالية، وتنتهي الجلسات المفتوحة. بعد عودة الحساب إلى الوضع الطبيعي، تبقى البيانات محفوظة ولا تتطلب إعادة إضافتها.
هذه نقطة فرق جوهرية بين إيقاف الوصول بشكل طارئ وتدمير محتويات الحساب. يمكن للمستخدم إغلاق الاتصالات الحالية، دون خوف من اختفاء بياناته أو إعداداته معها.
ماذا يحدث خلال وضعية البانك أثناء تغيير كلمة المرور
للوضعية طابع قاعدي آخر: فهي توقف جميع محاولات تغيير كلمة المرور غير المكتملة.
لا يهم متى تم طلب كلمة المرور الجديدة، قبل تفعيل وضعية البانك أم أثناء تفعيلها. لن يتم إكمال هذا الطلب تلقائيًا بعد انتهاء الوضع.
بعد نهاية البانك، تظل الكلمة التي كانت موجودة قبل التفعيل هي السارية.
هذا متعمد.
الإجراء المعتاد لترميم الحساب يقترح أن مالك الحساب يمكنه رؤية طلب غريب في التطبيق وإلغاؤه قبل تفعيل كلمة المرور الجديدة.
أما خلال البانك، لم يعد بإمكان الاعتماد على هذا السيناريو.
افترض أن المستخدم لاحظ نشاطًا مشبوهًا وفعّل وضعية الحماية. إذا سمحنا لعداد الاستعادة التلقائي بالاستمرار، يمكن للمهاجم طلب كلمة مرور جديدة أثناء البانك. وإذا انتهت مدة الانتظار قبل نهاية وضعية الحماية، فسيتم تفعيل كلمة المرور الجديدة قبل أن يعود الحساب إلى وضعه الطبيعي.
سوف يحصل تناقض: حاول المستخدم تعزيز الحماية، لكن خلال تلك الفترة، سمحت النظام بتغيير كلمة المرور دون أن يتمكن من إلغاء ذلك عبر التطبيق بطريقة عادية.
لذلك، وضعية البانك لا تؤجل الاستعادة، وإنما تقطع العملية غير المكتملة.
الطلبات التي تم تقديمها قبل تفعيل البانك لن تغير كلمة المرور بعد نهايته، والأمر نفسه ينطبق على الطلبات التي جاءت أثناء وضع الحماية.
وبذلك، لا يُنقل أي استعادة غير مكتملة عبر حد البانك.
وإذا أراد المستخدم أن يغير كلمة المرور من تلقاء نفسه في البداية
لا تقيّد وضعية البانك مالك الحساب من اتخاذ إجراءات معينة.
إذا كان التطبيق في يده، ويعتقد أن تغيير كلمة المرور ضروري، يمكنه بدء التغيير مباشرة وتأكيد كلمة المرور الجديدة عبر التطبيق.
وفي هذه الحالة، تنتهي عملية التغيير قبل تفعيل الوضع.
بعد ذلك، يفعيل وضعية الحماية بكلمة المرور الجديدة. فهذا هو الكلمة التي ستظل سارية بعد انتهاء البانك.
خيار آخر هو تفعيل البانك أولاً، ثم التحقيق في النشاط المشبوه، وبعد انتهائه، يمكنه بدء عملية تغيير كلمة المرور مجددًا إذا لزم الأمر.
الهدف من الآلية ليس جعل المستخدم يقيد نفسه في تسلسل واحد فقط، ولكن أن تغيير كلمة المرور غير المكتمل لا يتجاوز وضعية البانك.
وضعية البانك تمنح الوقت لاستعادة السيطرة على البريد الإلكتروني
هناك سيناريو مهم جدًا لهذا الميكانيزم: يعتقد المستخدم أن المشكلة ليست في مِلَدID أو الهاتف، وإنما في البريد الإلكتروني.
البريد يُستخدم كأحد قنوات الاستعادة، ولذلك أن يُخترق يشكل خطرًا حتى لو كانت كلمة مرور مِلَدID لا تزال غير معروفة للمهاجم.
في مثل هذه الحالة، يمكن للمستخدم تفعيل وضعية البانك ومباشرةً التركيز على المصدر: استعادة الوصول إلى البريد، تغيير الكلمة، إنهاء الجلسات غير المعروفة، والتحقق من إعدادات الأمان.
خلال فترة وضعية البانك، لا يُسمح لعملية الاستعادة بإنشاء كلمة مرور جديدة فعالة.
إذا حاول أحد الأشخاص الطلب مرة أخرى قبل تفعيل البانك، فإن هذه المحاولة لن تنجح. وإذا حاول شخص آخر ذلك أثناء البانك، فستكون النتيجة نفسها.
وبهذا يتوفر نافذة زمنية مؤقتة: تم إلغاء الوصولات النشطة، والبريد الإلكتروني المحتمل الاختراق لا يمكن استخدامه لإعداد كلمة جديدة، والمستخدم لديه الوقت لاستعادة السيطرة على بريده.
بعد انتهاء وضعية الحماية، تظل كلمة مرور مِلَدID القديمة سارية. وإذا استعاد السيطرة على البريد، فبإمكانه استخدام الحساب بشكل طبيعي، وإذا رغب بتغيير كلمة مرور مِلَدID، يمكن ذلك بشكل مستقل.
أسباب كثيرة تؤدي إلى تفعيل وضعية البانك
لتفعيل الوضع لا يحتاج الأمر لإثبات الاختراق أولاً.
قد يكون الهاتف في يد شخص آخر، أو ظهرت جلسة غير معروفة، أو تلقى المستخدم إشعارًا غير متوقع بظهور أو محاولة استعادة، أو تواجد عدة إشارات غير واضحة بشكل مباشر.
وفي مثل هذه الحالات، لا يحتاج المستخدم دائمًا للتحقيق قبل اتخاذ إجراء حماية أولي. أحيانًا يكون من الحكمة سحب الوصولات الحالية مؤقتًا، ثم التحقق من التفاصيل لاحقًا.
تقترح مِلَدID منطقًا بسيطًا: إذا اعتبر المالك أن الوضع خطير ولديه تطبيق موثوق، فإنه يجب أن يكون قادرًا على تفعيل السيناريو الوقائي فورًا. لا يشترط إثبات الهجوم أولاً.
لماذا تغيير كلمة المرور وحده غير كافٍ
كلمة المرور هي عنصر واحد من عناصر التوثيق. إذا كانت هناك جلسة فعالة أو توكن وصول، فإن تغيير كلمة المرور وحده لا يكفي لسحب جميع الوصولات السابقة.
لهذا، يعمل وضعية البانك بشكل أوسع. فهي تضع الحساب في حالة حماية خاصة، لا تقتصر على تغيير عنصر واحد، وإنما تعيد تأمين الحساب كلّه.
إلغاء الوصولات والجلسات النشطة؛
توقف محاولات تغيير كلمة المرور غير المكتملة قبل البانك؛
الطلبات أثناء البانك لن تؤثر على كلمة المرور بعد انتهائه؛
تظل كلمة المرور الحالية فعالة، وهي التي دخل بها الحساب وضعية البانك؛
يحصل المستخدم على وقت للتحقق من البريد والأجهزة والأسباب المحتملة؛
بعد انتهاء وضعية الحماية، يعود الحساب للوضع الطبيعي أو يغير كلمة المرور بشكل مستقل.
هذه ليست بديلًا عن آليات الأمان التقليدية، وإنما سيناريو طارئ يهدف إلى حماية الحساب وقت فقدان الثقة بحالة الوصول الحالية.
التطبيق المحمول كنقطة موثوقة
الميزة الجديدة متاحة في تطبيقات مِلَدID لنظام iOS و Android. في هذه البنية، يصبح الهاتف ليس مجرد جهاز آخر للدخول، بل نقطة موثوقة لإدارة أمان الحساب.
من خلال التطبيق يمكن:
تأكيد تغيير كلمة المرور المؤجل؛
إلغاء الطلب المريب؛
تفعيل وضعية البانك؛
إيقاف الوصولات النشطة على الأجهزة المختلفة؛
تحديد ما يجب أن يحدث بعد ذلك مع الحساب.
وفي الوقت نفسه، لا يلغي التطبيق التوثيق متعدد العوامل TOTP ولا يحل محله طرق الحماية الأخرى، وإنما يضيف قناة إدارة منفصلة للحالات التي لا تكفي فيها التوثيقات العادية لضمان أمان الحساب.
أين تقع حدود حماية مِلَدID
من المهم الفصل بين أمان نظام مِلَدID ذاته وسلامة البيئة التي يُستخدم فيها.
مِلَدID مُصمم بحيث لا ينشئ الخدمة قناة للحصول على كلمة المرور الحالية بشكل اعتيادي. كلمة المرور تُولد بواسطة النظام، لا يختارها المستخدم، ولا تُرسل عبر البريد الإلكتروني. عملية الاستعادة لا تكشف عن كلمة المرور، بل تبدأ بإنشاء جديدة.
لكن المستخدم لا يزال بإمكانه كشف بياناته بنفسه، مثل نقلها لشخص آخر أو إدخالها حيثما لا ينبغي.
مستوى أمان آخر هو جهاز المستخدم ونظام تشغيله. تطبيق الهاتف يعمل ضمن أنظمة الحماية في iOS وAndroid، ولا يمكنه استبدال أمان المنصة نفسها.
لهذا، يركز مِلَدID على المخاطر التي يمكنه التحكم فيها: توليد البيانات، التوثيق، التوكنات، الجلسات، الاستعادة، والاستجابة للاختراق المحتمل لقناة الاستعادة.
من الدخول إلى الاستجابة
عندما تعرفت على مِلَدID لأول مرة، وصفتُه كنظام هوية موحدة وإدارة الملف الشخصي. لكن مع إطلاق تطبيقات الهاتف وإضافة آليات حماية جديدة، أصبح الوصف ضيقًا جدًا.
الآن، النظام يجيب على أسئلة أكثر تعقيدًا:
ماذا تفعل عند محاولة استعادة غير متوقعة؛
كيف تستعيد الحساب بدون الوصول إلى التطبيق؛
كيف تحصل على وقت للتحقق قبل تفعيل كلمة المرور الجديدة؛
كيف تُلغي استعادة تم تفعيلها بدون مالك الحساب؛
كيف تسحب الوصولات النشطة؛
كيف تمنع البريد المخترق من تغيير كلمة المرور أثناء وضع البانك؛
كيف تستعيد السيطرة على قناة الاستعادة الخارجية؛
كيف تحافظ على بيانات المستخدم عند إيقاف جميع الوصولات النشطة؛
كيف تعود إلى العمل الطبيعي بعد التحقق من الحالة.
وفي النهاية، تتكون نموذج حماية متسلسلة.
الكلمة الحالية لمِلَدID لا تُرسل عبر قناة الاستعادة. الحصول على الوصول إلى البريد لا يكشفها بنفسه، لكنه قد يتيح بدء إنشاء كلمة مرور جديدة، لذا يُنَفَّذُ ببطء ويُمكن إلغاؤه عبر التطبيق الموثوق.
إذا كان ذلك غير كافٍ، فإن وضعية البانك تُقصِفُ الجلسات النشطة، وتلغي التوكنات، ولا تسمح للاستعادة غير المكتملة أن تتجاوز فترة الحماية.
المستخدم يحصل على وقت، وهو العنصر الأكثر أهمية في حالة الطوارئ: الوقت لاستعادة السيطرة على البريد، والتحقق من الأجهزة، وفهم ما حدث، وإعادة فتح الوصول بشكل عادي بعد ذلك.
ولهذا، فإن وضعية البانك في مِلَدID ليست مجرد زر «الخروج من كل مكان»، بل سيناريو استجابة مستقل لحالة يكون فيها الاعتماد على التوثيق العادي غير كافٍ، ويجب استعادة الثقة في بيئة الحساب.
لمزيد من المعلومات عن المشروع: meldid.de.