مدخل مبسّط · 9 دقائق
فهم التحقق من الهوية بوصفه نظامًا متكاملًا
التحقق من الهوية لا يقتصر على فحص كلمة مرور أو رمز أو بصمة أو مفتاح مرور. لفهم أمنه بصورة صحيحة، يجب النظر إليه كنظام متكامل يشمل التسجيل، وتسجيل الدخول، وقرارات المستخدم، وسياق الطلب، وتغيير بيانات الدخول، واستعادة الحساب، والجلسات الناتجة عن التحقق.
ما المقصود بالتحقق من الهوية؟
يُختصر مفهوم التحقق من الهوية أحيانًا في عبارة بسيطة: إثبات أن المستخدم هو الشخص الذي يدّعي أنه هو. وهذه نقطة بداية جيدة، لكنها لا تصف بدقة كل ما يحدث في أنظمة الهوية الرقمية الحديثة.
في النظام الرقمي، يهدف التحقق من الهوية عادةً إلى التأكد من أن شخصًا أو جهازًا أو عملية ما تستطيع إثبات السيطرة على وسيلة تحقق سبق ربطها بحساب أو هوية رقمية. وقد تكون وسيلة التحقق كلمة مرور، أو مفتاح أمان، أو هاتفًا مسجلًا، أو مفتاح مرور (Passkey)، أو بيانات اعتماد تشفيرية أخرى.
وهذا التفريق مهم؛ لأن نجاح التحقق من حساب لا يعني بالضرورة أن الخدمة تعرف الهوية الواقعية لصاحب الحساب. فقد تتمكن خدمة ما من التحقق بصورة صحيحة من صاحب حساب رقمي دون أن تعرف من يكون ذلك الشخص خارج حدود الخدمة.
تحديد الهوية والتحقق منها والتفويض ليست شيئًا واحدًا
تختلط ثلاثة مفاهيم ببعضها كثيرًا:
تحديد الهوية (Identification) يجيب عن السؤال: ما الحساب أو الهوية التي يتم الادعاء بها؟
يمكن لاسم المستخدم أو البريد الإلكتروني أو رقم الحساب أن يحدد للنظام الهوية التي يريد الشخص استخدامها.
التحقق من الهوية (Authentication) يجيب عن السؤال: هل يستطيع صاحب الطلب إثبات أحقيته في استخدام هذه الهوية؟
وهنا تظهر كلمات المرور، والرموز المؤقتة، ومفاتيح الأمان، والخصائص الحيوية، ومفاتيح المرور وغيرها من وسائل التحقق.
التفويض (Authorization) يجيب عن السؤال: ما الذي يُسمح لهذه الهوية بفعله بعد نجاح التحقق؟
فقد ينجح المستخدم في التحقق من هويته، لكنه لا يمتلك صلاحية الوصول إلى ملف معين أو وظيفة إدارية أو معاملة محددة.
يجب أن يتعامل النظام الآمن مع هذه المراحل بصورة صحيحة. فالتحقق القوي من الهوية لا يعالج خللًا في التفويض، ومعرفة اسم حساب ما لا تعني التحقق من هوية صاحبه.
ما الذي يمكن استخدامه للتحقق من الهوية؟
تُصنَّف وسائل التحقق عادةً إلى عوامل رئيسة.
يعتمد عامل المعرفة على شيء يعرفه المستخدم، مثل كلمة المرور أو الرقم السري.
ويعتمد عامل الحيازة على شيء يملكه المستخدم أو يسيطر عليه، مثل هاتف مسجل أو رمز مادي أو مفتاح أمان.
أما العامل الحيوي فيعتمد على سمة مرتبطة بالمستخدم، مثل بصمة الإصبع أو غيرها من الخصائص الحيوية.
كما تستخدم الأنظمة الحديثة وسائل تحقق تشفيرية تحفظ مفاتيح خاصة داخل الجهاز، وقد تتطلب تحققًا محليًا من المستخدم قبل السماح باستخدام المفتاح. وتُعد مفاتيح المرور (Passkeys) مثالًا مهمًا على ذلك.
هذه التصنيفات مفيدة، لكنها لا تكفي وحدها للحكم على أمن النظام. فقد تنتمي آليتان إلى عامل الحيازة، ومع ذلك تختلفان كثيرًا في مقاومة التصيّد، أو هجمات الترحيل، أو البرمجيات الخبيثة، أو سرقة الجهاز، أو إساءة استخدام مسارات الاستعادة.
ولهذا ينبغي تقييم التحقق من الهوية بوصفه نظامًا متكاملًا، وليس بوصفه عاملًا منفردًا.
التحقق من الهوية يبدأ قبل شاشة تسجيل الدخول
في الواقع، تبدأ عملية التحقق قبل أن يحاول المستخدم تسجيل الدخول.
قد يبدأ الحساب بإنشاء كلمة مرور، أو تسجيل هاتف، أو إنشاء مفتاح مرور، أو ربط وسيلة تحقق أخرى. ثم يستخدم الشخص هذه الوسائل لاحقًا في تسجيل الدخول، وقد يضيف أجهزة جديدة أو يحذف أجهزة قديمة، ويغير بيانات الدخول، ويستجيب لتحديات إضافية، وربما يحتاج في مرحلة ما إلى استعادة الحساب عندما يفشل المسار الاعتيادي.
كل مرحلة من هذه المراحل يمكن أن تغيّر مستوى أمن النظام.
فقد تكون وسيلة التحقق قوية، لكن عملية تسجيلها ضعيفة. وقد يكون تسجيل الدخول محميًا جيدًا، بينما تسمح عملية الاستعادة بتجاوز تلك الحماية. وقد يمنع العامل الثاني مهاجمًا حصل على كلمة المرور، لكنه يظل معتمدًا على قدرة المستخدم على فهم طلب الموافقة واتخاذ القرار الصحيح.
وتدعم دراستنا المنشورة في ACM Computing Surveys هذه النظرة الأوسع. فقد حللت الدراسة مديري كلمات المرور وأدوات التحقق الثنائي عبر أبعاد متعددة شملت الأمن، وسهولة الاستخدام، وقابلية النشر، والخصوصية. ولم تظهر آلية واحدة تتفوق في جميع الخصائص في الوقت نفسه.
وهذه النتيجة تتجاوز كلمات المرور والتحقق الثنائي. فتصميم التحقق من الهوية لا يتعلق بالسؤال عن «أفضل وسيلة» بصورة مطلقة، بل بالسؤال عن الخصائص التي يوفرها النظام، ونموذج التهديد الذي صُمم لمواجهته، والتكلفة التي يفرضها على المستخدم والنشر.
قد يتطلب التحقق من الهوية قرارًا أمنيًا من المستخدم
بعض وسائل التحقق تطلب من المستخدم إثبات معرفة سر أو حيازة جهاز فقط. لكن وسائل أخرى تطلب منه أيضًا اتخاذ قرار.
ويُعد التحقق متعدد العناصر عبر الإشعارات الفورية مثالًا واضحًا.
يمكن تبسيط العملية كالتالي:
- يبدأ المستخدم محاولة تسجيل الدخول.
- ترسل خدمة التحقق طلبًا إلى جهاز مسجل.
- يراجع المستخدم الطلب.
- يوافق عليه أو يرفضه.
- تستكمل الخدمة عملية الدخول إذا كانت الموافقة المطلوبة صحيحة.
قد يعمل البروتوكول تمامًا كما صُمم، ومع ذلك يتخذ المستخدم قرارًا خاطئًا.
فإذا استطاع مهاجم إنشاء طلب يبدو مشروعًا، فقد يعالج النظام بصورة صحيحة موافقة لم يكن ينبغي للمستخدم منحها أصلًا.
وتوضح دراستنا حول أسلوب المقارنة والتأكيد في التحقق الثنائي عبر الإشعارات الفورية هذه الحدود. ففي الحالات المشروعة، تجاوزت معدلات النجاح 95%. أما عند إدخال محاولات احتيالية، فلم ينجح المشاركون في التعرف بصورة صحيحة إلا على نحو نصف محاولات الهجوم تقريبًا.
أي أن عملية التحقق يمكن أن تكون صحيحة تقنيًا، بينما يظل القرار الأمني البشري عرضة للخطأ.
يحاول أسلوب المقارنة والتأكيد، المعروف غالبًا باسم مطابقة الأرقام (Number Matching)، تحسين الموافقة التقليدية عبر الإشعارات الفورية من خلال مطالبة المستخدم بمطابقة معلومات مرتبطة بمحاولة تسجيل الدخول بدلًا من الاكتفاء بالضغط على زر «موافقة».
تساعد هذه الخطوة على ربط الموافقة بطلب محدد، لكنها لا تلغي الموافقات الخاطئة تلقائيًا. فلا يزال الانتباه، وتصميم الواجهة، وتوقيت الطلب، والمعلومات المعروضة للمستخدم عوامل مؤثرة في النتيجة الأمنية.
سهولة الاستخدام جزء من النموذج الأمني
يُنظر أحيانًا إلى سهولة الاستخدام على أنها مرحلة لاحقة: نصمم الآلية الأمنية أولًا، ثم نجعلها سهلة الاستخدام.
لكن هذا الفصل غير دقيق في الأنظمة التي تعتمد على تفاعل الإنسان.
فالمستخدم جزء من مسار تنفيذ العملية الأمنية. هو من يفسر الإشعار، وينتقل بين الأجهزة والتطبيقات، ويقارن المعلومات، ويتعامل مع التحذيرات، ويقرر ما إذا كان الطلب متوقعًا أو مشبوهًا.
وقد تؤدي الطلبات المتكررة أو الواجهات غير الواضحة إلى الاعتياد. وفي التحقق عبر الإشعارات الفورية، على سبيل المثال، يمكن لتكرار الطلبات أن يشجع الموافقة التلقائية بدلًا من التحقق المتأني.
لكن العلاقة بين الأمن وسهولة الاستخدام ليست ببساطة: «كلما قلّ الاحتكاك كان أفضل» أو «كلما زادت الخطوات أصبح النظام أكثر أمانًا».
في دراستنا اللاحقة The Mobile Paradox، حللنا أسلوب المقارنة والتأكيد في سياقات مختلفة للأجهزة. ولم تظهر النتائج أثرًا سلبيًا موحدًا لاستخدام الهاتف. فقد كان المشاركون من الفئة متوسطة المهارة أكثر قدرة على رفض محاولات الهجوم بصورة صحيحة عند استخدام الهاتف مقارنة بالحاسوب، بينما كان الفرق محدودًا لدى المشاركين ذوي المهارة الأعلى.
لا تعني هذه النتيجة أن الاحتكاك في الهاتف مفيد دائمًا، بل توضح أن تصميم التفاعل يمكن أن يغيّر السلوك الأمني.
يكون الاحتكاك مفيدًا عندما يوجّه انتباه المستخدم نحو القرار الأمني المهم.
قد تؤدي إزالة كل خطوة إلى جعل التحقق أسرع، لكنها قد تحذف أيضًا فرصًا مفيدة لفهم ما يحدث. وفي المقابل، قد تضيف الخطوات غير الضرورية إرهاقًا دون حماية حقيقية.
لذلك لا ينبغي أن يكون الهدف هو تقليل التفاعل إلى الحد الأدنى.
بل تصميم التفاعل المناسب في اللحظة المناسبة.
السياق والارتباط جزء من الأمن
من المهم أيضًا أن نفهم بما ترتبط وسيلة التحقق أو الموافقة.
لنعد إلى مطابقة الأرقام. قد يساعد الرقم المعروض على شاشتين في ربط إشعار بعملية تحقق محددة، لكنه لا يوضح بالضرورة:
- ما الخدمة التي بدأت طلب التحقق؟
- ما الحساب الذي تتم محاولة الوصول إليه؟
- ما المتصفح أو الجهاز الذي سيحصل على الجلسة الناتجة؟
- من أين جاء الطلب؟
- هل يتوافق هذا الطلب مع ما يقوم به المستخدم في تلك اللحظة؟
تكتسب هذه الأسئلة أهمية أكبر عندما يستطيع المهاجم إنشاء طلب تحقق يبدو مشروعًا، لكنه يحاول توجيه الوصول الناتج إلى سياق مختلف.
في بحث Hardening Push MFA: A Standards-Based Context Architecture for Number Matching درسنا كيف يمكن تعزيز مطابقة الأرقام من خلال إضافة سياق أوضح حول طلب التحقق والخدمة أو الجهة التي تطلبه.
والمبدأ هنا أوسع من التحقق عبر الإشعارات الفورية:
يجب أن يفهم المستخدم ما الذي تتم الموافقة عليه، لا أن يعرف فقط كيف ينفذ الموافقة.
ولهذا يحتاج نظام التحقق إلى ارتباط واضح بين وسيلة التحقق، والطلب الذي تتم الموافقة عليه، والخدمة المعنية، والجلسة أو المعاملة الناتجة عندما يكون ذلك ذا صلة.
خمس أسئلة لتقييم نظام التحقق من الهوية
يمكن البدء بخمس أسئلة عملية.
1. ما الذي يتم إثباته؟
هل يتحقق النظام من معرفة سر، أو حيازة جهاز، أو السيطرة على مفتاح تشفيري، أو سمة حيوية، أو مجموعة من هذه العناصر؟
2. بماذا ترتبط عملية التحقق؟
هل يرتبط الإثبات أو قرار الموافقة بوضوح بالحساب الصحيح، والخدمة المقصودة، والجهاز، وجلسة المتصفح، أو المعاملة؟
3. ما القرار المطلوب من المستخدم؟
هل يطلب النظام من المستخدم تنفيذ خطوة فقط، أم يتوقع منه اكتشاف ما إذا كان هناك شيء مشبوه؟
هذا الفرق مهم؛ لأن النظام الذي يعتمد على حكم المستخدم يجب أن يقدم له معلومات كافية لاتخاذ ذلك القرار بصورة واقعية.
4. ماذا يحدث عندما يفشل المسار الاعتيادي؟
كيف يعاد تعيين بيانات الدخول؟ وكيف يُستبدل الجهاز المفقود؟ وكيف تسجل وسيلة تحقق جديدة؟ وهل تسمح عملية الاستعادة بتجاوز حماية قوية موجودة في تسجيل الدخول الاعتيادي؟
5. ما الذي يحتاج المهاجم إلى تجاوزه؟
يجب ألا يقتصر نموذج التهديد على وسيلة التحقق نفسها. فقد يستهدف المهاجم البروتوكول، أو الواجهة، أو المستخدم، أو الجهاز، أو عملية التسجيل، أو الاستعادة، أو الجلسة التي تنشأ بعد نجاح التحقق.
تنقلنا هذه الأسئلة من سؤال عام:
«هل طريقة التحقق هذه آمنة؟»
إلى سؤال أكثر فائدة:
«تحت أي ظروف يبقى نظام التحقق من الهوية آمنًا؟»
التحقق من الهوية نظام متكامل
التحقق من الهوية ليس كلمة مرور.
وليس رمزًا مؤقتًا.
وليس إشعارًا فوريًا، أو بصمة، أو مفتاح أمان، أو مفتاح مرور.
هذه كلها مكونات داخل النظام.
أما نظام التحقق نفسه فيشمل الهويات، ووسائل التحقق، والأجهزة، والبروتوكولات، والواجهات، وقرارات المستخدم، وسياق الطلب، وعمليات دورة الحياة، ومسارات الاستعادة، والوصول الناتج بعد نجاح التحقق.
وفهم العلاقة بين هذه العناصر هو الأساس لتقييم التحقق من الهوية في العالم الحقيقي.
ومن الطبيعي أن نبدأ بعد ذلك بأقدم عوامل المعرفة وأكثرها انتشارًا حتى اليوم: كلمة المرور.
يتناول المقال التالي كيفية عمل التحقق باستخدام كلمات المرور، ولماذا ما زالت كلمات المرور واسعة الاستخدام، ومن أين تأتي حدودها الأمنية، ولماذا يجب النظر إلى أمن كلمة المرور بوصفه جزءًا من نظام تحقق أكبر.
المراجع
- An In-Depth Analysis of Password Managers and Two-Factor Authentication Tools
- Usability and Security Analysis of the Compare-and-Confirm Method in Mobile Push-Based Two-Factor Authentication
- The Mobile Paradox: How Interface Friction Can Improve 2FA Security
- Hardening Push MFA: A Standards-Based Context Architecture for Number Matching
النقاش والأسئلة
شارك في النقاش.
هل لديك سؤال، أو وجهة نظر مختلفة، أو تجربة عملية مرتبطة بهذا الموضوع؟ أرحب بالنقاشات الهادفة حول الأفكار والأدلة المطروحة في هذا المقال.