كيفيّة تحديد طريقة الـ hash من التمثيل النصّيّ لقيمة الـ hash - إجراء عمليّ لتضييق المرشّحين عبر الطول والمحارف والـ prefix

كثيراً ما نواجه مواقف نريد فيها أن نحدّد «ما هذا الـ hash؟» عند رؤية سلسلة مثل 5f4dcc3b5aa765d61d8327deb882cf99 أو $2b$12$... متبقّية في السجلّات أو في DB. في ترحيل الأنظمة القائمة، وتحقيق طرق المصادقة، وتحليل السجلّات، والتكامل مع أنظمة طرف ثالث، ليس من النادر أن نتوقّف عند هذه النقطة.

غير أنّ الخطر هنا هو الحكم القاطع بناءً على الطول وحده.
أن تنظر إلى سلسلة hex من 64 خانة وتقول «هذا SHA-256» هو حكم متعجّل. SHA3-256 وSHA-512/256 وBLAKE2s-256 والمخرَج الافتراضيّ بحجم 32-byte لـ BLAKE3 يمكن أن تعطي الطول نفسه. على العكس من ذلك، فإنّ صيغ التخزين التي تتضمّن الـ prefix والمعاملات مثل $2b$ أو $argon2id$ يمكن تحديدها بدقّة عالية من السلسلة وحدها.

في هذا المقال نستعمل كلمة hash بمعنى واسع، فلا يقتصر الأمر على message digest مثل MD5 / SHA-2 / SHA-3، بل يشمل أيضاً التمثيلات النصّيّة لتخزين كلمات المرور مثل bcrypt / scrypt / Argon2 / PBKDF2.
المحتوى منظَّم استناداً إلى الوثائق الرسميّة المنشورة حتّى أبريل 2026 من RFC وNIST وLinux crypt(5) وApache وDjango وSpring Security.

1. الخلاصة أوّلاً

إن لخّصنا أوّلاً بإيجاز، فإنّ الخلاصة كالتالي.

• صيغ التخزين التي تحمل prefix أو فاصلاً يمكن تحديدها إلى حدّ بعيد من السلسلة وحدها.
  مثلاً: $argon2id$..., $2b$..., $5$..., $6$..., {SHA}..., pbkdf2_sha256$...

• مجرّد سلسلة hex مجرّدة أو Base64 لا تتجاوز عادةً «تضييق المرشّحين».
  مثلاً: 32 hex قد تكون MD5، لكنّها قد تكون من MD4 / NTLM

• مجموعة المحارف لا تقلّ أهميّة عن الطول.
  وجود + / = يدلّ على Base64 وفق RFC 4648، ووجود . مع فاصل $ يدلّ على عائلة crypt(3)، وهذا النوع من التمييز فعّال.

• إذا أردنا تثبيتاً 100% فلا بدّ من السياق.
  هل المصدر /etc/shadow أم .htpasswd أم auth_user في Django أم Spring Security؟ يتغيّر الحديث بحسب ذلك.

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

2. جدول التحديد بنظرة واحدة

2.1 ما يمكن تحديده تقريباً عبر الـ prefix أو علامات الصيغة

قوّة التحديد لها المعاني التالية.

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

نقطة هذا الجدول هي أنّ الصيغ التي يكون لمحارفها الأولى معنى تكون قويّة.
وبالأخصّ ما يُفصَل بـ $...$، فاحتمال أن يكون من عائلة Unix crypt(3) / MCF / PHC مرتفع، والنظر إلى الـ prefix قبل الطول هو الأسرع.

2.2 جدول تضييق المرشّحين بالطول لـ hex / Base64 المجرَّد

هذا هو الجدول لرؤية «مجرّد سلسلة digest» بلا prefix.
في التمثيلات التي تختلط فيها : أو - أو فراغات، نزيل أوّلاً الفواصل ونعدّ الطول.

المهمّ هنا أنّ تطابق الطول لا يعني تحديد الطريقة بصورة قطعيّة.
وبالأخصّ، hex بطول 32 / 64 / 128 يحتمل مرشّحين كثيرين، والجزم بناءً على ذلك وحده يجعل احتمال الخطأ كبيراً.

2.3 أمثلة شائعة يسهل الالتباس فيها

3. إجراء التحديد في العمل الفعليّ

من هنا فصاعداً، ننظّم بالترتيب كيفيّة الفحص في الممارسة.
الترتيب الموصى به هو prefix ← الفواصل ← مجموعة المحارف ← الطول ← السياق.

3.1 ابدأ بالنظر إلى الرموز الأولى

من المحرف الأوّل إلى نحو عشرة محارف، يمكن تضييق المرشّحين كثيراً.

• $argon2id$ / $argon2i$ / $argon2d$
  نشكّ بقوّة في PHC string format لـ Argon2. يسهل تتبّع المكوّنات بالنظر إلى عمود مثال في 2.1.

• $2a$ / $2b$ / $2y$
  نشكّ بقوّة في bcrypt.

• $1$ / $5$ / $6$ / $7$ / $y$
  نشكّ في password hash من عائلة Unix crypt(3).

• {SHA} / {SSHA} / {MD5} / {SMD5}
  نشكّ في تمثيلات عائلة LDAP / Apache.

• {bcrypt} / {pbkdf2} / {scrypt}
  نشكّ في صيغ تخزين تحمل علامة التطبيق كما في Spring Security.

النصيحة هنا هي النظر ليس فقط إلى «الخوارزميّة الأساسيّة» بل إلى «صيغة التخزين» أيضاً.
مثلاً $6$ ليس «digest الخاصّ بـ SHA-512»، بل «سلسلة password hash تستعمل SHA-512». الخلط هنا يؤدّي إلى انحراف لاحق في التحقيق.

3.2 انظر إلى عدد محارف الفصل

ثمّ نتفقّد فواصل مثل $, :, {}, ,, =.

• وجود عدّة $
  نشكّ في صيغة تحوي معاملات وsalt وhash معاً. الأمثلة النمطيّة هي Argon2 وbcrypt وsha256crypt وsha512crypt.

• البدء بـ {name}
  نشكّ في غلاف يصرّح باسم الطريقة كما في LDAP / Spring Security.

• صيغ مثل algo:salt:hash أو algo$iterations$salt$hash
  نشكّ في صيغ خاصّة بإطار عمل أو تطبيق. المثال النمطيّ هو pbkdf2_sha256$iterations$salt$hash في Django.

كلّما ازدادت الفواصل في السلسلة، صار تحديد الطريقة أيسر.
وعلى العكس، مجرّد كتلة hex أو Base64 وحدها يجعل الأمر مبهماً.

3.3 انظر إلى مجموعة المحارف

مجموعة المحارف لا تقلّ أهميّة عن الطول.

تمثيل hex

إن كانت السلسلة مكوّنة فقط من [0-9a-fA-F]، فأوّل ما نشكّ فيه هو تمثيل hex.
في هذه الحالة عدد المحارف ÷ 2 = طول البايتات الخامة.

• 32 hex ← 16 bytes
• 40 hex ← 20 bytes
• 64 hex ← 32 bytes
• 128 hex ← 64 bytes

Base64 / Base64url وفق RFC 4648

وجود + / = يدلّ في الغالب على Base64 العاديّ.
وجود - _ يدلّ على Base64url.
قد تُحذف علامة الـ padding =، فلذلك يحتمل أن نرى 43 / 44, 86 / 88 كأطوال محتملة.

radix64 من عائلة crypt

إذا ظهرت . و/ وكان الفاصل من نوع $...$، فمن الأنسب الشكّ في alphabet عائلة crypt قبل Base64 الاعتياديّ.
bcrypt وsha256crypt وsha512crypt وmd5crypt وyescrypt وscrypt كلّها تستخدم هذه العائلة من المحارف.

هذه نقطة بسيطة المظهر، لكنّها فعّالة جدّاً.
أن نظنّ «إنّها Base64 تالف لأنّ فيها .» يجعلنا نُغفل bcrypt أو عائلة crypt(3).

3.4 عدّ الطول

بعد تفقّد مجموعة المحارف، نأتي إلى الطول.
الفكرة بسيطة.

• في hex: طول البايتات الخامة = عدد المحارف / 2
• في Base64: عدد المحارف ≒ 4 × ceil(طول البايتات الخامة / 3)
  مع ملاحظة أنّ حذف = للـ padding يقصّر الطول من 0 إلى 2 محرفاً

في هذه المرحلة نضيّق المرشّحين.
لكن من الآمن عدم القفز إلى الجزم بأنّ 64 hex هي SHA-256 مؤكّدة.

3.5 التثبيت بالسياق

ما يحسم في النهاية هو السياق. وهنا نقترب من 100%.

• موجود في /etc/shadow
  نشكّ في صيغ password hash لـ Linux مثل $y$, $6$, $5$, $1$

• موجود في .htpasswd
  نشكّ في عائلة Apache مثل $apr1$, {SHA}, bcrypt

• في إعدادات Django أو في auth_user.password
  نشكّ في صيغة Django مثل pbkdf2_sha256$... أو argon2$...

• في جدول مصادقة Spring Security
  نشكّ في صيغة مع {id} مثل {bcrypt}... أو {pbkdf2}...

• 32 hex قرب تكامل SMB / AD
  نضع احتمال عائلة NTLM / MD4 في مقدّمة الذهن

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

4. أخطاء التحديد الشائعة

4.1 الجزم بأنّ 64 hex = SHA-256

هذا متكرّر بكثرة.
طبعاً SHA-256 مرشّح قويّ، لكن توجد عدّة طرق تنتج مخرَجاً بحجم 32-byte. SHA3-256 وSHA-512/256 وBLAKE2s-256 والمخرَج الافتراضيّ لـ BLAKE3 لها الطول نفسه.

الطول مادّة لتكوين مجموعة المرشّحين، لا مادّة للتثبيت.

4.2 سوء فهم $6$ على أنّه plain SHA-512

$6$... هو prefix sha512crypt.
هذه ليست «hex digest لـ SHA-512»، بل سلسلة password hash تتضمّن salt وعدد rounds.

وبالمثل،

• $5$ هو sha256crypt
• $1$ هو md5crypt

من اللحظة التي يظهر فيها prefix، لم يعد الأمر «مجرّد digest».

4.3 الظنّ بأنّ {SHA} يعني «إمّا SHA-256 أو SHA-512»

في سياق Apache أو LDAP، لا يعني {SHA} معنىً غامضاً «من عائلة SHA».
بل يدلّ في كثير من الحالات على SHA-1 digest مرمَّز بـ Base64. و{SSHA} هو salted SHA-1.

التعامل مع {SHA} بصورة غامضة على أنّه «شيء من نوع SHA» اعتماداً على المظهر فقط، يجعلنا نخطئ في كود التحقّق ومعالجة الترحيل.

4.4 معاملة password hash و content hash كشيء واحد

«سلسلة الـ hash» نفسها قد تختلف أهدافها.

• digest للتحقّق من سلامة الملفّ
• digest لتوقيع API
• hash / KDF لتخزين كلمة المرور

هذه الثلاثة قد تتشابه في المظهر، لكنّ التعامل معها مختلف.
وبالأخصّ password hash، إذ كثيراً ما يضمّ في السلسلة salt وrounds وmemory cost وparallelism. ولا يمكن كشف ذلك بفكر «المقارنة بين digest خامين».

4.5 نسيان XOF أو digest متغيّر الطول

SHAKE128 / SHAKE256 من نوع XOF، فيمكن اختيار طول المخرَج بحرّيّة.
BLAKE2 يتيح أيضاً تغيير digest length، وBLAKE3 له extendable output.

أي إنّ افتراض «هذا الطول يعني هذه الطريقة» يخطئ إذا اعتمد كثيراً على digest كلاسيكيّ ثابت الطول.

5. ترتيب التحقّق عند الرغبة في التثبيت 100%

في الترحيل وتكامل المصادقة، نحتاج أخيراً إلى التثبيت. عندئذٍ يقلّ احتمال الحوادث إذا اتّبعنا الترتيب التالي.

5.1 تحديد مصدر التخزين

أوّلاً نحدّد من أين أتت السلسلة.

• من shadow الخاصّ بـ Linux؟
• من basic auth الخاصّ بـ Apache / Nginx؟
• من LDAP؟
• من Django / Spring Security؟
• من DB لتطبيق خاصّ؟

غالباً ما تكون مواصفات مصدر التخزين أقوى من السلسلة وحدها.

5.2 البحث عن «صيغة التخزين» في الوثائق الرسميّة

ثمّ نبحث ليس عن اسم الخوارزميّة بل عن صيغة التخزين.

• Django password format
• Spring Security password storage format
• crypt(5) sha512crypt format
• Apache htpasswd password formats

استخدام كلمات مفتاحيّة مثل format / storage / encoding يجعل العثور أسرع.

5.3 إن وُجد plaintext معروف، فجرِّب التحقّق فعليّاً بطرق المرشّحين

إن توفّر حساب اختباريّ أو plaintext معروف، فإنّ أسرع طريق هو حساب الـ hash فعليّاً بطرق المرشّحين والمقارنة.
في password hash، يلزم استخراج salt وrounds من السلسلة وإعادة الحساب.

5.4 التحقّق من كود التطبيق أو الإعدادات

إذا كان موضوع التحقيق نظاماً داخل شركتنا، فإنّ النظر إلى الكود والإعدادات هو الأكثر تأكيداً في النهاية.

• المكتبات المستخدمة
• إعدادات إطار العمل
• خيارات وقت التوليد
• ترميز الإخراج (hex / Base64 / Base64url / crypt alphabet)

النظر إلى هذه عادةً يحسم الأمر.

5.5 التخزين بعلامة الطريقة من أجل المستقبل

إن كنّا في موقع التصميم لما هو آتٍ، فاختيار صيغة تتضمّن اسم الطريقة في السلسلة يجعل الترحيل المستقبليّ أسهل بكثير.

• PHC string format لـ Argon2
• {id}encodedPassword في Spring Security
• algo$iterations$salt$hash في Django
• صيغ عائلة Unix crypt(3) ذات الـ prefix

عند فعل ذلك، يقلّ ارتباك من ينظر إلى السلسلة لاحقاً.
وبالعكس، فإنّ تصميم يخزّن «مجرّد 64 hex» في DB ليس لطيفاً مع الذات المستقبليّة.

6. الخلاصة

عند التمييز بين طرق الـ hash من تمثيلها النصّيّ، يكون التنظيم أسهل بهذا الترتيب.

1. هل يوجد prefix؟
2. ما محارف الفصل؟
3. ما مجموعة المحارف؟
4. كم بايتاً يوازي الطول؟
5. ما سياق مصدر التخزين؟

أهمّ نقطتين كالتالي.

• صيغ التخزين المسبوقة بـ prefix يسهل تحديدها كثيراً
• مجرّد hex / Base64 لا يتجاوز عادةً مجموعة المرشّحين

لذلك يصبح القرار في العمل كما يلي.

• إذا كان $argon2id$..., $2b$..., $6$..., {SHA}..., pbkdf2_sha256$...، فيمكن التقدّم كثيراً بالسلسلة وحدها
• إذا كان مجرّد hex من 32 / 40 / 64 / 128 خانة، فلا نجزم بل نعتبره «تضييق المرشّحين»
• إذا لزم التثبيت فعلاً، فلا بدّ من النظر إلى منتج مصدر التخزين وإعداداته وكوده

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

7. الخدمات التي يتّصل بها هذا الموضوع

الاستشارة التقنيّة ومراجعة التصميم

في تحديد طريقة password hash المتبقّية في DB قائمة، وترحيل البنية التحتيّة للمصادقة، وتحقيق سجلّات الأنظمة المختلطة Windows / Web، نحتاج إلى تنظيم لا يقتصر على مظهر السلسلة، بل يمتدّ إلى تطبيق مصدر التخزين وسياسة الترحيل. تنظيم العمل من تحديد الطريقة إلى تصميم الترحيل دفعةً واحدة يقلّل الحوادث.

تحقيق الأعطال وتحليل الأسباب

ليس من النادر أن يتعطّل التحقيق عند «لا أعرف ما هذه السلسلة فلا يمكنني التقدّم في التحقّق». فصل أين تتقرّر الطريقة بين السجلّات وملفّات الإعداد ومخطّط DB وكود التطبيق يجعل تحديد السبب أسرع كثيراً.

8. مراجع

1. RFC 1321 - The MD5 Message-Digest Algorithm
2. NIST FIPS 180-4 - Secure Hash Standard (SHA-1, SHA-2, SHA-512/224, SHA-512/256)
3. NIST FIPS 202 - SHA-3 Standard: Permutation-Based Hash and Extendable-Output Functions
4. PHC string format specification
5. Argon2 reference implementation
6. RFC 7693 - The BLAKE2 Cryptographic Hash and Message Authentication Code (MAC)
7. BLAKE3 C README - default output length and extendable output
8. crypt(5) - prefixes and hashed passphrase formats
9. Apache HTTP Server 2.4 - Password Formats
10. slappasswd(8) - RFC 2307 schemes such as {SHA} and {SSHA}
11. Django documentation - example of pbkdf2_sha256$...
12. Spring Security - DelegatingPasswordEncoder storage format {id}encodedPassword

مقالات ذات صلة

أحدث المقالات التي تشترك في نفس الوسوم. عمّق فهمك بمواضيع مرتبطة.

الملف الشخصي للمؤلف

صفحة الملف الشخصي لمؤلف المقالة.

غو كومورا

مؤسّس شركة كومورا سوفت ذ.م.م.

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