المصادقة الثنائية 2FA وMFA: أي طريقة تحميك فعلاً؟

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

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

• ما المصادقة المتعددة MFA فعلاً: ثلاثة أنواع من العوامل، لا ثلاث كلمات مرور.
• كيف تعمل كل طريقة: الرسائل القصيرة، والبريد، وتطبيق TOTP، وإشعار الموافقة، ومفتاح الأمان، ومفاتيح المرور.
• تجربة عملية: نبني TOTP من الصفر ونتحقق منه من اختبارات RFC 6238 الرسمية.
• الفكرة الأهم: ما معنى «مقاوم للتصيد»، ولماذا يسقط رمز TOTP ولا يسقط مفتاح المرور.
• تجربة عملية: نرى بأنفسنا كيف ينقل المهاجم رمز TOTP بينما يفشل توقيع مفتاح المرور.
• سلم الطرق من الأقوى إلى الأضعف، وماذا تختار، وأخطاء شائعة.

ما المصادقة المتعددة MFA فعلاً؟

المصادقة المتعددة العوامل Multi-Factor Authentication تعني أن تثبت هويتك بأكثر من عامل، من أنواع مختلفة. والأنواع ثلاثة، كما تبين الصورة التالية:

• شيء تعرفه Something you know: كلمة المرور، رقم PIN، جواب سؤال. وهو العامل الأضعف لأنه يسرق بالتصيد والتسريب دون أن تلاحظ.
• شيء تملكه Something you have: الهاتف، تطبيق مصادقة، مفتاح أمان مادي. والمهاجم يحتاج الجهاز نفسه، وهذا أقوى عامل عملي اليوم.
• شيء أنت Something you are: بصمة، وجه، قزحية. مريح، لكن له عيبان مهمان. الأول أنه لا يتغير إن تسرب، فلا تستطيع أن «تغير بصمتك» كما تغير كلمة مرورك، فإذا سرقت قوالب بصمتك مرة فهي مسروقة للأبد. والثاني أنه احتمالي لا قطعي: ماسح البصمة قد يخطئ أحياناً فيقبل شخصاً آخر (قبول خاطئ) أو يرفضك أنت (رفض خاطئ). ولهذين السببين لا تستخدم السمات الحيوية عادة كعامل يرسل عبر الشبكة، وإنما محلياً على جهازك لفتح مفتاح مخزن فيه: فبصمتك تفتح قفل هاتفك الذي يحوي مفتاح المرور، والموقع لا يرى بصمتك أبداً، وإنما يرى توقيع المفتاح. وهذا هو الاستخدام الصحيح للسمات الحيوية: بوابة محلية إلى شيء تملكه، لا سر يسافر.

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

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

وهناك مفهوم مرتبط يفيدك: المصادقة المتدرجة Step-up Authentication. فليس كل فعل يحتاج القوة نفسها: الاطلاع على رصيدك أقل حساسية من تحويل مبلغ كبير. ولذلك تطلب بعض الخدمات العامل الثاني فقط عند الأفعال الحساسة أو الدخول من جهاز جديد، لا في كل مرة. وهذا يوازن بين الأمان والراحة: حماية قوية حيث تهم، وأقل احتكاكاً في المعتاد. ومن يصمم نظاماً يستفيد من هذا المبدأ، فلا يرهق المستخدم بعامل ثان في كل نقرة، ويركزه حيث الخطر.

ولماذا نسميها أحياناً ثنائية 2FA وأحياناً متعددة MFA؟ الثنائية 2FA حالة خاصة من المتعددة: عاملان بالضبط. والمتعددة MFA مصطلح أعم يشمل عاملين أو أكثر. وفي الاستخدام اليومي يقصد بهما الشيء نفسه غالباً: أضف عاملاً فوق كلمة المرور. وما يهم ليس العدد، وإنما أن يكون العامل الإضافي من نوع مختلف وقوي.

كيف تعمل كل طريقة؟

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

• رمز الرسائل القصيرة SMS: يرسل الموقع رمزاً إلى رقم هاتفك، فتكتبه. وهو الأضعف لعدة أسباب: الرسائل تمر عبر شبكة الاتصالات التي يمكن اعتراض رسائلها في بعض الحالات، ويمكن للمهاجم أن ينقل رقمك إلى شريحة يملكها بهجوم تبديل الشريحة SIM Swapping (يقنع شركة الاتصالات أنك أنت وأنك فقدت شريحتك)، فتصله الرموز بدلاً منك، وهو أيضاً قابل للنقل بالتصيد كأي رمز. وتبديل الشريحة تحديداً خطر على من يملكون أرصدة كبيرة (حسابات مالية، عملات رقمية)، لأن رقم الهاتف يصبح نقطة ضعف واحدة. ومع ذلك، رمز الرسائل خير من لا شيء بكثير، فيوقف الهجمات الآلية الجماعية التي تجرب كلمات مرور مسربة دون عامل ثان. فالقاعدة: فعله إن لم يوجد أقوى منه، لكن ارتق عنه حيثما استطعت، خصوصاً للحسابات المالية.
• رمز البريد الإلكتروني: يرسل الموقع رمزاً إلى بريدك. ومشكلته مزدوجة: أولاً أن بريدك نفسه قد يكون مخترقاً، وإن كان مخترقاً فكل حساباتك التي ترسل رموزها إليه مخترقة معه، فيصبح البريد نقطة انهيار واحدة. وثانياً أنه رمز تكتبه كأي رمز، فيلتقط بالتصيد. ولهذا فهو عامل ضعيف: لا تجعل بريدك العامل الثاني لحسابات مهمة، واحم البريد نفسه بأقوى عامل، فهو مفتاح استعادة كل شيء آخر، ومن يملك بريدك يعيد تعيين كلمات مرور حساباتك.
• تطبيق المصادقة TOTP: تطبيق على هاتفك يعرض رمزاً من ست خانات يتغير كل 30 ثانية، ويحسبه من سر مشترك بينه وبين الموقع ومن الوقت الحالي، دون اتصال بالشبكة. وهو أقوى من الرسائل، لأن الرمز لا يمر بشبكة الاتصالات فلا يعترض، ولا يحتاج اتصالاً، ولا يتأثر بتبديل الشريحة. ومسألة مهمة فيه: بعض التطبيقات تزامن أسرارك سحابياً بين أجهزتك (لراحة الاستعادة)، وبعضها يبقيها على الجهاز فقط (لأمان أعلى). والمزامنة أسهل إن فقدت هاتفك، لكنها تعني أن أسرارك في حساب سحابي يجب أن يكون محمياً بقوة هو نفسه. واختر بحسب موازنتك بين الراحة والأمان، واحم الحساب السحابي للتطبيق بأقوى عامل. وسوف نبني TOTP بأنفسنا بعد قليل لنفهمه من الداخل.
• إشعار الموافقة Push: يرسل الموقع إشعاراً إلى تطبيق على هاتفك، فتضغط «موافقة». وهو مريح، لكن له خطر اسمه إرهاق الموافقات MFA Fatigue: يرسل المهاجم (الذي يملك كلمة مرورك) طلبات دخول متكررة، فتضغط «موافقة» بالخطأ أو من الإزعاج أو ظناً أنه خلل. وقد وقعت اختراقات كبيرة موثقة بهذه الطريقة بالضبط: المهاجم يملك كلمة المرور، ويقصف الموظف بإشعارات حتى يوافق على واحد. ولذلك تضيف التطبيقات الجيدة رقماً يجب أن تطابقه مع الشاشة Number Matching، فلا تكفي الموافقة العمياء، بل تكتب رقماً يظهر على شاشة الدخول، فلا يستطيع المهاجم أن يجعلك توافق دون أن تراه. والقاعدة: لا توافق أبداً على إشعار لم تبدأه أنت، فالإشعار الذي يصلك دون أن تحاول الدخول يعني أن أحداً يملك كلمة مرورك ويحاول، فغيرها فوراً.
• مفتاح الأمان المادي Security Key: جهاز صغير (مثل YubiKey) تلمسه عند الدخول، فيثبت هويتك بتوقيع رقمي. ومفاتيح المرور Passkeys هي التقنية نفسها (معيار FIDO2/WebAuthn) لكن المفتاح مخزن في جهازك (هاتفك أو حاسبك) بدل جهاز منفصل. وهذان أقوى الأنواع، لأنهما مقاومان للتصيد بتصميمهما، كما سنرى.

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

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

تجربة عملية: نبني TOTP ونتحقق منه من المعيار

تطبيق المصادقة ليس صندوقاً سحرياً، وإنما خوارزمية بسيطة منشورة في معيار رسمي. وأفضل طريقة لتفهمها أن تبنيها بنفسك، ثم تتحقق أنها صحيحة بمقارنتها بالاختبارات الرسمية التي ينشرها المعيار. والخوارزمية مبنية على طبقتين: HOTP في RFC 4226 التي تحسب رمزاً من سر وعداد، وTOTP في RFC 6238 التي تجعل العداد هو الوقت مقسوماً على 30 ثانية. نكتبها بـ Python بالمكتبة القياسية فقط، في ملف totp.py:

import hashlib, hmac, struct, time, base64

def hotp(key: bytes, counter: int, digits: int = 6, algo=hashlib.sha1) -> str:
    msg = struct.pack(">Q", counter)                 # عداد 8 بايت (RFC 4226 §5.1)
    mac = hmac.new(key, msg, algo).digest()
    offset = mac[-1] & 0x0F                           # الاقتطاع الديناميكي (§5.3)
    code = (struct.unpack(">I", mac[offset:offset+4])[0] & 0x7FFFFFFF) % (10 ** digits)
    return str(code).zfill(digits)

def totp(key: bytes, t: int, step: int = 30, t0: int = 0, digits: int = 6, algo=hashlib.sha1) -> str:
    counter = (t - t0) // step                        # RFC 6238 §4.2
    return hotp(key, counter, digits, algo)

والصورة التالية تبين ما يفعله هذا الكود خطوة بخطوة:

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

والآن نتحقق أن تطبيقنا صحيح، لا بأن نثق به، بل بمقارنته بقيم الاختبار الرسمية في الملحق B من RFC 6238، وهي قيم محسوبة يدوياً في المعيار لثلاث خوارزميات وستة أوقات:

seeds = {
    hashlib.sha1:   b"12345678901234567890",
    hashlib.sha256: b"12345678901234567890123456789012",
    hashlib.sha512: b"1234567890123456789012345678901234567890123456789012345678901234",
}
expected = {   # time -> {algo: code}  من الملحق B في RFC 6238
    59:          {"SHA1": "94287082", "SHA256": "46119246", "SHA512": "90693936"},
    1111111109:  {"SHA1": "07081804", "SHA256": "68084774", "SHA512": "25091201"},
    1111111111:  {"SHA1": "14050471", "SHA256": "67062674", "SHA512": "99943326"},
    1234567890:  {"SHA1": "89005924", "SHA256": "91819424", "SHA512": "93441116"},
    2000000000:  {"SHA1": "69279037", "SHA256": "90698825", "SHA512": "38618901"},
    20000000000: {"SHA1": "65353130", "SHA256": "77737706", "SHA512": "47863826"},
}
names = {hashlib.sha1: "SHA1", hashlib.sha256: "SHA256", hashlib.sha512: "SHA512"}
ok = fail = 0
for t in sorted(expected):
    for algo, name in names.items():
        ours = totp(seeds[algo], t, digits=8, algo=algo)
        m = ours == expected[t][name]
        ok += m; fail += (not m)
        print(f"{t:>12}  {name:6}  {ours}  {expected[t][name]}  {'OK' if m else 'FAIL'}")
print(f"\n{ok} vectors matched, {fail} failed")

# ورمز واقعي من ست خانات لسر تطبيق، كما يعرضه تطبيق المصادقة
key = base64.b32decode("JBSWY3DPEHPK3PXP")            # سر اختباري، لا حساب حقيقي
now = int(time.time())
print(f"now={now}  6-digit TOTP: {totp(key, now)}  (valid {30 - now % 30}s)")

نشغله في حاوية (وفي Git Bash على Windows أضف MSYS_NO_PATHCONV=1 واستخدم "$(pwd -W)"):

docker run --rm -v "$PWD":/w python:3.13.17-slim python3 /w/totp.py

          59  SHA1    94287082  94287082  OK
          59  SHA256  46119246  46119246  OK
          59  SHA512  90693936  90693936  OK
  1111111109  SHA1    07081804  07081804  OK
          ...
 20000000000  SHA512  47863826  47863826  OK

18 vectors matched, 0 failed

now=1793195740  6-digit TOTP: 085645  (valid 20s)

في المخرج أعلاه لاحظ التالي:

• استخدمنا ثلاث خوارزميات بصمة (SHA1 وSHA256 وSHA512) وستة أوقات، فصارت ثمانية عشر اختباراً، وهي القيم نفسها المكتوبة في الملحق B من المعيار، محسوبة بشكل مستقل من واضعي المعيار.
• الاختبارات الثمانية عشر كلها طابقت (18 vectors matched, 0 failed)، أي أن تطبيقنا يحسب القيم نفسها التي يحسبها المعيار بالضبط. وهذا ما يجعل تطبيق المصادقة على هاتفك يتفق مع الموقع: كلاهما ينفذ الخوارزمية نفسها على السر والوقت نفسيهما، فيخرجان الرمز نفسه دون أن يتصلا.
• التحقق من اختبارات رسمية هو كيف تثق بأي تطبيق تشفير: لا تصدق أنه صحيح لأنه «يعمل»، بل لأنه يطابق قيماً محسوبة بشكل مستقل. وهذه عادة محلل الأمن.
• الرمز الأخير من ست خانات، وصلاحيته 20 ثانية، وهو ما يعرضه تطبيقك على هاتفك، يتغير كل 30 ثانية. ولأنه يعتمد على الوقت، يجب أن يكون وقت هاتفك والموقع متقاربين، ولهذا تفشل الرموز أحياناً إذا كان وقت هاتفك خاطئاً.
• لاحظ أن الكود كله أقل من عشرين سطراً بالمكتبة القياسية، دون أي مكتبة خارجية. فالمصادقة الثنائية بتطبيق ليست سحراً، بل خوارزمية منشورة يستطيع أي مطور أن يبنيها ويتحقق منها، وهذا جزء من قيمة المعايير المفتوحة: يستطيع الجميع تنفيذها والتأكد من صحتها، فلا تعتمد على ثقة أعمى بمورد واحد.

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

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

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

والآن وقد فهمنا TOTP، نستطيع أن نرى عيبه الجوهري الذي يشترك فيه مع الرسائل والبريد: الرمز سر تنقله أنت، وما تنقله يمكن أن ينقله غيرك.

ما معنى «مقاوم للتصيد»؟

هذه أهم فكرة في المقال. فالتصيد الحديث لا يسرق كلمة مرورك فقط، بل يسرق رمز المصادقة الثنائية معها في اللحظة نفسها. كيف؟ يضعك المهاجم على صفحة مزيفة، فتكتب كلمة مرورك فيعرفها، ثم يطلب منك الرمز، فتكتبه، فيأخذه المهاجم ويدخله في الموقع الحقيقي خلال ثوان، فيدخل. وهذا يسمى الوسيط Adversary-in-the-Middle. والسبب أن الرمز (من الرسائل أو البريد أو TOTP) سر عام لا يعرف أين كتب: الرمز 455083 صحيح سواء كتبته في الموقع الحقيقي أو المزيف، فمن يأخذه يستخدمه. والصورة التالية تبين ذلك:

أما مفتاح الأمان ومفاتيح المرور (FIDO2/WebAuthn) فتحل هذا جذرياً: فهي لا تعطي سراً تنقله، وإنما تثبت هويتك بتوقيع رقمي مربوط بنطاق الموقع الحقيقي. فحين تحاول الدخول، يوقع مفتاحك على اسم النطاق الذي أنت عليه فعلاً، فإذا كنت على موقع مزيف، يوقع لنطاق المزيف، وحين ينقل المهاجم هذا التوقيع إلى الموقع الحقيقي يرفضه لأنه مصدر لنطاق آخر. وهكذا لا يعمل مفتاح المرور أصلاً على الموقع المزيف، فلا يوجد ما ينقله المهاجم. وهذا ما يسميه المعيار مقاومة التصيد Phishing Resistance، ولنرها بتجربة.

تجربة عملية: الرمز ينقل والتوقيع لا

سوف نبني نموذجاً مبسطاً جداً يبين الفكرتين: أن رمز TOTP يقبل إذا نقل في الوقت، وأن توقيعاً مربوطاً بالنطاق يفشل إذا نقل إلى نطاق آخر. احفظ phish_resist.py (نموذج تعليمي مبسط، لا تطبيق FIDO2 كامل):

import hashlib, hmac, struct, time, base64, os
def totp(key, t, step=30, digits=6):
    c = struct.pack(">Q", t // step); mac = hmac.new(key, c, hashlib.sha1).digest()
    o = mac[-1] & 0xF
    return str((struct.unpack(">I", mac[o:o+4])[0] & 0x7FFFFFFF) % 10**digits).zfill(digits)

print("== 1) TOTP: نفس الرمز يقبل ممن ينقله في النافذة الزمنية ==")
key = base64.b32decode("JBSWY3DPEHPK3PXP"); now = int(time.time())
code = totp(key, now)
print(f"   المستخدم يكتب الرمز {code} في موقع مزيف")
print(f"   المهاجم ينقل نفس {code} إلى الموقع الحقيقي خلال 30 ثانية -> يقبل:",
      totp(key, now) == code)

print("\n== 2) توقيع مربوط بالنطاق (كما يفعل مفتاح المرور) ==")
device_key = os.urandom(32)                           # مفتاح الجهاز (نموذج مبسط)
def sign(origin, ch): return hmac.new(device_key, origin.encode() + ch, hashlib.sha256).hexdigest()
def verify(origin, ch, sig): return hmac.compare_digest(sign(origin, ch), sig)
ch = os.urandom(16)
real = "https://bank.example.com"; fake = "https://bank-fake.example.net"
sig_on_fake = sign(fake, ch)                          # الجهاز يوقع لنطاق المزيف الذي أنت عليه
print(f"   أنت على النطاق المزيف، الجهاز يوقع له: {fake}")
print(f"   المهاجم ينقل التوقيع إلى الموقع الحقيقي، فيفحصه بنطاقه هو:")
print(f"   verify at real origin:", verify(real, ch, sig_on_fake), "-> مرفوض: التوقيع مربوط بالنطاق المزيف")

== 1) TOTP: نفس الرمز يقبل ممن ينقله في النافذة الزمنية ==
   المستخدم يكتب الرمز 455083 في موقع مزيف
   المهاجم ينقل نفس 455083 إلى الموقع الحقيقي خلال 30 ثانية -> يقبل: True

== 2) توقيع مربوط بالنطاق (كما يفعل مفتاح المرور) ==
   أنت على النطاق المزيف، الجهاز يوقع له: https://bank-fake.example.net
   المهاجم ينقل التوقيع إلى الموقع الحقيقي، فيفحصه بنطاقه هو:
   verify at real origin: False -> مرفوض: التوقيع مربوط بالنطاق المزيف

في المخرج أعلاه لاحظ التالي:

• رمز TOTP قبل حين نقل إلى الموقع الحقيقي، لأنه لا يحمل أي معلومة عن المكان الذي كتب فيه، فهو مجرد رقم صحيح في نافذته الزمنية. هذا هو عيب كل ما تنقله بيدك.
• التوقيع فشل حين نقل، لأنه حسب على اسم النطاق المزيف، والموقع الحقيقي يفحصه على اسمه هو، فلا يتطابقان. هذا هو جوهر مقاومة التصيد: الربط بالنطاق يجعل التوقيع عديم الفائدة في أي مكان آخر.
• لاحظ أن الفرق ليس في «قوة التشفير»، فكلاهما يستخدم HMAC قوياً، وإنما في ماذا نحمي: TOTP يحمي سرية رمز ينتقل، ومفتاح المرور يربط الإثبات بالمكان. والدرس أن أمان النظام ليس في قوة الخوارزمية وحدها، بل في تصميم ما تثبته ولمن وأين.
• لاحظ أننا استخدمنا نموذجاً مبسطاً (HMAC بدل التوقيع بالمفتاح العام الحقيقي)، لأن الهدف توضيح المبدأ لا بناء FIDO2 كامل. لكن المبدأ نفسه: مفتاح المرور الحقيقي يوقع بمفتاح خاص لا يغادر جهازك على اسم النطاق، والموقع يتحقق بالمفتاح العام، والنطاق جزء من التوقيع.

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

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

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

سلم الطرق: أيها تختار؟

بعد أن فهمنا كيف تعمل كل طريقة ولماذا تتفاوت، نستطيع أن نرتبها من الأقوى إلى الأضعف، كما تبين الصورة التالية:

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

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

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

ولتبسيط القرار، اتبع ثلاث خطوات كما في الصورة التالية: حدد أهمية الحساب، ثم انظر ما تدعمه الخدمة، ثم جهز الاستعادة:

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

الاستعادة: الباب الخلفي الذي ينساه الجميع

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

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

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

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

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

مفاتيح المرور: نحو الدخول بلا كلمة مرور

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

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

الجانب السعودي

الضوابط الأساسية للأمن السيبراني ECC لا تترك المصادقة المتعددة توصية، بل متطلباً في مواضع محددة: ففي حماية البريد (المكون 2-4) تطلب المصادقة متعددة العوامل للدخول عن بعد وللبريد، وفي إدارة الهوية والوصول (المكون 2-2) تطلبها للدخول عن بعد وللحسابات المميزة. أي أن كلمة المرور وحدها لا تكفي نظاماً لهذه الحالات الحساسة، وهو ما يتفق مع كل ما شرحناه. ولاحظ أن الضوابط تربط اختيار عوامل المصادقة بنتيجة تقييم أثر فشل المصادقة، أي كلما زادت حساسية ما تحميه، ارتقيت في قوة العامل، وهو المنطق نفسه الذي رأيناه في سلم الطرق. وشرح قراءة الضوابط في مقال الضوابط الأساسية NCA ECC.

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

أخطاء شائعة Common Mistakes

• اعتبار كل المصادقة الثنائية سواء: رمز الرسائل القصيرة ومفتاح المرور كلاهما «ثنائية»، لكن بينهما فرق هائل في مقاومة التصيد.
• الاكتفاء بسؤال أمان كعامل ثان: جواب «ما اسم أول حيوان أليف لك؟» شيء تعرفه، لا شيء تملكه، وإجابته تعرف من مواقع التواصل، فليس مصادقة متعددة حقيقية.
• الضغط على كل إشعار موافقة: إرهاق الموافقات هجوم حقيقي، فلا توافق إلا على دخول بدأته أنت، واستخدم مطابقة الأرقام.
• جعل البريد العامل الثاني لكل شيء: إن اخترق بريدك سقطت كل الحسابات التي ترسل رموزها إليه، فاحم البريد بأقوى عامل.
• إهمال رموز الاستعادة: عدم حفظها يقفلك خارج حسابك، وحفظها في مكان مكشوف يتجاوز مصادقتك كلها.
• عامل ثان واحد على جهاز واحد: فقدان الجهاز يضيع كل شيء، فاحتفظ بطريقة استعادة ثانية.
• تأجيل التفعيل بحثاً عن الأفضل: أي مصادقة ثنائية اليوم خير من انتظار مفتاح المرور غداً، فعل المتاح ثم ارتق.

قائمة عملية

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

الخلاصة

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

• المصادقة المتعددة تعني عاملين من نوعين مختلفين (تعرفه، تملكه، أنت)، لا عاملين من النوع نفسه، فهي تضيف شيئاً لا ينتقل فوق شيء ينتقل.
• «شيء تملكه» طرق كثيرة تتفاوت كثيراً، فمن يفهم آلية كل طريقة يحكم على قوتها.
• بنينا TOTP بأنفسنا وتحققنا منه من 18 اختباراً رسمياً في RFC 6238، فهو خوارزمية بسيطة على سر ووقت.
• الفرق الأهم مقاومة التصيد: الرمز سر تنقله فيلتقطه المهاجم وينقله، وتوقيع مفتاح المرور مربوط بالنطاق فلا يصلح لغيره.
• رأينا بالتجربة كيف يقبل الموقع الحقيقي رمز TOTP منقولاً، بينما يرفض توقيعاً صدر لنطاق مزيف.
• اصعد في سلم الطرق ما استطعت، وابدأ بالمتاح: أي مصادقة ثنائية خير من كلمة مرور وحدها.
• لا تنس الاستعادة: احفظ رموزها، واحتفظ بطريقة ثانية، فالعامل المفقود يقفلك خارج حسابك، والباب الخلفي الضعيف يبطل أقوى باب أمامي.

تدريب عملي Practice

• عدل تطبيق TOTP ليقبل نافذة تسامح: أن يقبل رمز الخطوة السابقة والتالية (للتعامل مع فرق الوقت البسيط)، واشرح لماذا يوسع هذا سطح الهجوم قليلاً.
• أنشئ سراً جديداً بـ base32، وولد به رمزاً، ثم أدخله في تطبيق مصادقة حقيقي على هاتفك (بإدخال السر يدوياً)، وتأكد أن الرمزين يتطابقان، فهذا يثبت أن تطبيقك والتطبيق التجاري ينفذان المعيار نفسه.
• راجع حساباتك المهمة، واكتب لكل واحد نوع المصادقة الثنائية المفعل عليه وأقوى نوع يدعمه، ثم ارتق بأهمها إلى الأقوى.
• اقرأ ملحق الاختبارات في RFC 4226، وتحقق أن تطبيقك لـ HOTP (قبل إضافة الوقت) يطابق قيمه، فتكون قد فهمت الطبقة الأساس تحت TOTP.

سجل التحديثات

• أكتوبر 2026: كتابة المقال، وبناء TOTP والتحقق منه من اختبارات RFC 6238 الرسمية (18/18) على python:3.13.17-slim، وتجربة نقل الرمز مقابل التوقيع المربوط بالنطاق.