مولّد التجزئة (Hash)

دالة التجزئة هي خوارزمية رياضية تأخذ مدخلاً بأي حجم — حرفاً واحداً أو ملفاً بحجم جيجابايت — وتُنتج مخرجاً ثابت الطول يُسمّى Hash أو Digest أو بصمة رقمية. تغيير بِت واحد في المدخل يُغيّر معظم بِتّات الهاش الناتج تغييراً جذرياً، وهي خاصية تُعرف بـ Avalanche Effect.

الهاش اتجاه واحد: من السهل حساب SHA-256("password") ولكن من المستحيل عملياً استرجاع كلمة password من الهاش. هذه الخاصية تجعل الهاش الأساس لمصادقة كلمات السر، توقيع الملفات، ومنظومات Blockchain بأكملها.

دالة هاش تشفيرية موثوقة يجب أن تحقق أربع خصائص:

• Deterministic: نفس المدخل يُنتج نفس الهاش دائماً.
• Pre-image resistance: من المستحيل عملياً إيجاد مدخل ينتج هاشاً معيناً.
• Second pre-image resistance: بمعرفة مدخل x، من المستحيل إيجاد y ≠ x بنفس الهاش.
• Collision resistance: من المستحيل إيجاد أي مدخلين مختلفين بنفس الهاش.

عندما تنكسر إحدى هذه الخصائص — كما حدث لـ MD5 و SHA-1 — تُصبح الخوارزمية غير صالحة للاستخدامات الأمنية.

صُمِّمت MD5 عام 1991 على يد Ron Rivest، وتُنتج هاشاً بطول 128 بِت (32 رمز hex). كانت لسنوات الخيار الافتراضي لـ Checksums والتحقق من سلامة الملفات وحتى لتخزين كلمات السر.

عام 2004، أُعلن عن أول هجوم تصادم عملي على MD5. وفي 2008، استخدم باحثون التصادم لتزوير شهادة SSL موثوقة من CA حقيقي. اليوم يمكن إنتاج تصادم MD5 على لابتوب عادي خلال ثوانٍ.

القاعدة: MD5 ممنوعة في أي استخدام أمني. لا توقيع، لا كلمات سر، لا شهادات. الاستخدام الوحيد المقبول هو Checksum للتأكد من عدم تلف الملف بسبب خطأ نقل (ليس عبثاً متعمداً).

نشرت NSA معيار SHA-1 عام 1995، بهاش 160 بِت. ظلّ المعيار الصناعي لـ Git و TLS وتوقيع الشهادات حتى منتصف العقد الثاني من الألفية.

في فبراير 2017، أعلنت Google عن هجوم SHAttered — أول تصادم عملي لـ SHA-1 — حيث أنتج الباحثون ملفَّي PDF مختلفين بنفس هاش SHA-1. منذ ذلك الحين، أزالت المتصفحات الرئيسية دعم شهادات SHA-1، وانتقلت GitHub و Git تدريجياً إلى SHA-256.

استخدامات Git الداخلية لـ SHA-1 لا تزال آمنة من ناحية الخطأ العرضي، لكن لا تعتمد على SHA-1 لأي قرار أمني جديد.

SHA-2 ليست خوارزمية واحدة بل عائلة: SHA-224، SHA-256، SHA-384، SHA-512. الأرقام تُشير لطول الهاش بالبِت. أكثرها استخداماً هي:

• SHA-256: هاش 256 بِت (64 رمز hex). المعيار الصناعي اليوم، يستخدمه Bitcoin و TLS 1.3 وأغلب الشهادات الرقمية.
• SHA-384: هاش 384 بِت. يستخدم في TLS لبعض مجموعات التشفير القوية.
• SHA-512: هاش 512 بِت. أسرع من SHA-256 على معالجات 64-bit لأنه يعمل على كلمات 64-بِت بدلاً من 32.

لا توجد حتى الآن أي هجمات عملية على SHA-2، ومن المتوقع أن يبقى آمناً لسنوات. إن لم يكن لديك سبب محدد لاختيار غيره، فـ SHA-256 هو الإجابة الافتراضية.

عام 2015 اعتمد NIST معيار SHA-3 بعد مسابقة عامة فازت بها خوارزمية Keccak. الفكرة لم تكن أن SHA-2 مكسور — بل لتوفير بديل بهندسة مختلفة جذرياً (sponge construction بدلاً من Merkle–Damgård) تحسّباً لاكتشاف ثغرة مستقبلية في SHA-2.

SHA-3 ليس بديلاً عن SHA-256 في الاستخدام اليومي، لكن إن كنت تبني نظاماً يحتاج تنوّعاً في عائلات الخوارزميات (Defense in Depth)، فهو خيار ممتاز.

أكبر خطأ شائع: SHA-256(password) ثم تخزينه في قاعدة البيانات. هذه ممارسة غير آمنة لسببين:

1. السرعة: SHA-256 مُصمَّمة لتكون سريعة جداً. GPU حديث يحسب مليارات الهاشات في الثانية، مما يجعل هجمات brute-force عملية.
2. Rainbow tables: جداول جاهزة لملايين كلمات السر الشائعة وهاشاتها. بدون salt، يتم كسر قاعدة بياناتك خلال دقائق.

الحلّ ليس إضافة salt فقط — بل استخدام دوال هاش بطيئة عمداً ومُصمّمة لكلمات السر.

هذه ثلاث دوال هاش مخصّصة لكلمات السر، تتميّز بـ:

• بطء قابل للتعديل: يمكنك ضبط معامل التكلفة (cost factor) ليصبح كل هاش يستغرق ~100ms مثلاً، مما يجعل brute-force مستحيلاً.
• Salt تلقائي: الدالة تُضيف salt عشوائياً وتخزّنه ضمن المخرج.
• مقاومة GPU/ASIC: argon2 و scrypt يستهلكان ذاكرة كبيرة عمداً، مما يجعل المهاجم لا يستفيد من العتاد المتخصص.

التوصيات الحالية (2026): argon2id هو الخيار الأول لأي مشروع جديد. bcrypt مقبول للمشاريع القائمة. scrypt خيار وسط. PBKDF2 مقبول قانونياً (FIPS) لكنه أضعف من الثلاثة.

Salt هي قيمة عشوائية فريدة لكل مستخدم تُضاف لكلمة السر قبل التجزئة: hash(password + salt). تُخزَّن مع الهاش. الهدف:

• منع Rainbow tables — كل salt يُنتج هاشاً مختلفاً حتى لنفس كلمة السر.
• منع كشف مستخدمَين لهما نفس كلمة السر من خلال تطابق الهاشات.
• زيادة تكلفة هجوم brute-force ضد قاعدة بيانات كاملة.

Pepper قيمة سرية إضافية لا تُخزَّن في قاعدة البيانات بل في متغيّر بيئة أو خزنة أسرار (Vault). فائدتها: لو تسرّبت قاعدة البيانات فقط، يبقى الهاش غير قابل للكسر بدون معرفة الـ pepper.

HMAC (Hash-based Message Authentication Code) يدمج دالة هاش مع مفتاح سري لإنتاج توقيع. الصيغة المُبسّطة:

HMAC(key, message) = hash((key XOR opad) || hash((key XOR ipad) || message))

الاستخدام الأهم: التحقق من أصالة وسلامة الرسائل بدون تشفيرها. JWT يستخدم HMAC-SHA256 (الخوارزمية HS256). webhooks من Stripe و GitHub و Slack تُوقَّع بـ HMAC ليتأكد المستقبِل أنها فعلاً من المصدر.

فرق مهم: HMAC ليس هاش عادي + key. لا تستخدم SHA256(secret || message) لأنه عرضة لهجمات Length Extension. استخدم مكتبة HMAC دائماً.

عند تحميل أداة من الإنترنت، يُنشر معها هاش (عادة SHA-256) على الموقع الرسمي. تحسب الهاش محلياً وتقارنه — إن تطابق فالملف لم يُعدَّل أثناء النقل.

هذا يحميك من:

• أخطاء نقل أو تلف بسبب الشبكة.
• Mirror sites مزوَّرة تُقدّم ملفاً معدَّلاً.
• هجمات Man-in-the-Middle (إذا كنت تحصل على الهاش من قناة آمنة منفصلة).

المهم: الهاش يحميك فقط إذا حصلت عليه من مصدر موثوق منفصل عن الملف نفسه. إن كان كلاهما من نفس الموقع المخترَق، فالحماية صفر.

Bitcoin يستخدم SHA-256 بشكل مكثّف:

• كل block يحتوي هاش الـ block السابق — أي تعديل قديم يُلغي كل ما بعده.
• Proof of Work هو في جوهره: ابحث عن قيمة nonce تجعل SHA-256(SHA-256(block_header)) أصغر من target معين.
• عناوين Bitcoin مشتقّة من هاش المفتاح العام.

Ethereum يستخدم Keccak-256 (نسخة قبل اعتماد SHA-3 الرسمي، تختلف قليلاً عن SHA-3-256). لذلك لو حسبت "SHA-3" لعنوان Ethereum بمكتبة قياسية، قد تحصل على نتيجة مختلفة عمّا تتوقّع.

ما الفرق بين MD5 و SHA-256؟

MD5 ينتج هاش 128 بِت وهو مكسور أمنياً منذ 2004 (يمكن إيجاد تصادمين خلال ثوانٍ). SHA-256 ينتج 256 بِت وهو المعيار الصناعي الحالي بدون أيّ هجوم عملي معروف. استخدم SHA-256 افتراضياً لكل احتياجاتك الأمنية. MD5 مقبول فقط للتحقق من سلامة الملفات ضدّ الأخطاء العَرَضية.

هل يمكن عكس الهاش لاستعادة النص الأصلي؟

لا، دوال الهاش اتجاه واحد رياضياً. لكن للنصوص الشائعة (مثل كلمات السر الضعيفة) يمكن للمهاجم بناء قاموس مسبق — يحسب هاش ملايين الكلمات الشائعة ويبحث عن تطابق. لذا لا يكفي مجرد "تجزئة" كلمة السر؛ يجب استخدام Salt فريد ودالة بطيئة مثل bcrypt أو argon2.

لماذا SHA-256 غير مناسب لكلمات السر؟

لأنه سريع جداً عمداً. GPU حديث يحسب مليارات هاشات SHA-256 في الثانية، ممّا يجعل brute-force عملياً. كلمات السر تحتاج دوال بطيئة عمداً مثل argon2id، bcrypt، أو scrypt. هذه تستغرق ~100 مللي ثانية لكل هاش، فيستحيل تجربة مليار كلمة محتملة.

ما هو Salt ولماذا أحتاجه؟

Salt قيمة عشوائية فريدة تُضاف لكلمة السر قبل التجزئة وتُخزَّن مع الهاش. فائدته: منع Rainbow Tables (كل salt ينتج هاشاً مختلفاً)، منع كشف مستخدمَين يستخدمان نفس كلمة السر، وإجبار المهاجم على كسر كل حساب على حِدة. الطول الموصى به: 16 بايت عشوائية على الأقل.

ما الفرق بين Hash و HMAC؟

Hash عملية تجزئة عامة بدون مفتاح: SHA256(data). HMAC يدمج هاش مع مفتاح سرّي: HMAC-SHA256(key, data). الفائدة: التحقق من أنّ الرسالة جاءت فعلاً من طرف يعرف المفتاح، وأنّها لم تُعدَّل. Webhooks من Stripe و GitHub توقَّع بـ HMAC. JWT بخوارزمية HS256 يستخدم HMAC-SHA256.

هل بياناتي تُرفع للخادم؟

لا. كل العمليات تجري محلياً في متصفّحك عبر Web Crypto API و JavaScript خالص لـ MD5. لا توجد طلبات شبكة، لا تخزين، لا تتبّع لمحتوى ما تُدخِله.

الأداة في أعلى الصفحة تحسب MD5 و SHA-1 و SHA-256 و SHA-384 و SHA-512 لأي نص أو ملف فوراً — كل المعالجة محلية ولا يُرفع شيء إلى أي خادم. للاستخدام الأمني الجاد (كلمات السر، توقيع API) استخدم مكتبة متخصصة في الخادم؛ لهذه الأداة دور مساعد للتعلّم والتحقق السريع.