إجراء عمليّ لتمييز طريقة الـ hash من تمثيلها النصّيّ

كثيراً ما نحتاج إلى الحكم على «ما هذا الـ 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.

القرّاء المستهدفون من يتولّى ترحيل نظام قائم، أو تحقيق طريقة المصادقة، أو تحليل السجلّات، ويريد فصل «سلسلة تشبه الـ hash» التي بين يديه. يكفي كمعرفة مسبقة أن تعرف ما تمثيل hex وما Base64.

علماً بأنّ إجراءات هذا المقال تُستعمل فقط على سلاسل في بيئة تديرونها أنتم، أو في بيئة صُرِّح لكم بالتحقيق فيها. استخراج password hash لحساب شخص آخر، أو تحليل hash في نظام بلا صلاحية، لا يُبرَّر حتّى لو كان الغرض تحقيقاً. أوامر التحقّق الواردة لاحقاً تفترض حساباً اختباريّاً أو عيّنة صنعتموها بأنفسكم.

جدول المحتويات

1. الخلاصة أوّلاً
2. جداول التحديد بنظرة واحدة
3. إجراء التحديد في العمل الفعليّ
4. أخطاء التحديد الشائعة
5. ترتيب التحقّق عند الرغبة في التثبيت 100%
6. الخلاصة
7. الخدمات التي يتّصل بها هذا الموضوع
8. المراجع

في المخطّط، يشير الخطّ المتّصل إلى علاقة قائمة دائماً، ويشير الخطّ المتقطّع إلى علاقة مشروطة (شروط قيامها مذكورة في شرح كلّ علاقة في الصفحة التفصيليّة). القائمة الكاملة للعلاقات (المجموع 27، مع الأدلّة ودرجة اليقين) وتعريفات المفاهيم الرئيسة مجمّعة في صفحة تفاصيل خريطة المعرفة (باليابانية). البيانات: JSON-LD / Turtle

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

نلخّص أوّلاً بإيجاز.

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

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

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

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

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

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

قبل قراءة الجداول، نرتّب أربعة أسماء «للصيغة» تظهر في هذا المقال. تُستعمل في سياقات متشابهة، لكنّ ما تشير إليه مختلف.

باختصار، crypt(3) دالّة، وcrypt(5) مواصفة صيغة مخرجاتها، وMCF الاسم الشائع لتلك الصيغة، وPHC string format إعادة تدوين لها. عندما تقول الجداول لاحقاً «PHC string format» أو «عائلة crypt»، فاقرأها بهذا الفصل.

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

«قوّة التحديد» في الجدول تعني ما يلي.

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

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

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

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

كيف تُقرأ عمود «عدد محارف Base64»: العمود يضع حالتين جنباً إلى جنب: مع حشو = / بدونه. Base64 وفق RFC 4648 تُحاذى على وحدات من 4 محارف، لذلك لا تُلحق = واحد أو اثنان في النهاية إلّا حين لا يكون طول البايتات الخام مضاعفاً لـ 3. في JWT أو التضمين في URL كثيراً ما تُسقط هذه =، فقد يظهر الـ digest نفسه بطول 43 محرفاً وبطول 44. بالمقابل، عند 48 بايتاً مثلاً (مضاعف لـ 3) لا يحدث حشو، فيتكرّر الرقم نفسه 64 / 64. عند تضييق المرشّحين بالطول، قابل دائماً الرقمين معاً.

المهمّ هنا أنّ تطابق الطول لا يعني تحديد الطريقة بصورة قطعيّة. وبالأخصّ، 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. قد تُحذف علامة الحشو =، فلذلك يحتمل أن نرى 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) مع ملاحظة أنّ حذف = للحشو يقصّر الطول من 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 نضع احتمال تجزئة NT (على أساس 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 كلاسيكيّ ثابت الطول.

4.6 معاملة «NTLM» و«تجزئة NT» كأنّهما الشيء نفسه

هذا حديث عن المصطلحات، لكنّه فعّال جدّاً في تحقيقات Windows / AD.

• تجزئة NT: قيمة من 16 بايتاً تُحسب بترميز كلمة المرور UTF-16LE ثمّ تطبيق MD4. تظهر كـ hex بطول 32 خانة، مثل 8846f7eaee8fb117ad06bdd830b7586c. في المواصفة تُعرَّف بـ NTOWFv1(Passwd, User, UserDom) = MD4(UNICODE(Passwd)). هذا التعريف وارد كما هو في بند NTLM v1 Authentication من MS-NLMP المذكور في المرجع 13.
• NTLM: اسم بروتوكول مصادقة يستعمل تلك القيمة مفتاحاً لتحدٍّ / استجابة. ليس اسم صيغة للسلسلة.

في الميدان يُفهم تعبير «NTLM hash»، لكن عند إسقاط الأمر على جدول التحديد الأدقّ أن نكتب تجزئة NT (على أساس MD4). بهذا الفصل لا يختلط تحديد الصيغة («هل هذه الـ 32 hex هي MD5 أم تجزئة NT؟») بحديث البروتوكول («هل هذا الاتّصال NTLM أم Kerberos؟»).

علماً بأنّ تجزئة NT بلا salt. كلمة المرور نفسها تنتج دائماً الـ 32 hex نفسها، لذا فإنّ «صفوف 32 hex بلا salt في جدول آتٍ من AD» دليل بحدّ ذاته.

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 إن وُجد متن معروف، فجرِّب التحقّق فعليّاً بطرق المرشّحين

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

قالب الإجراء ثلاث مراحل في كلّ طريقة:

1. استخرج salt والمعاملات من السلسلة
2. أعد الحساب على المتن المعروف بالـ salt والمعاملات نفسها
3. انظر هل السلسلة الناتجة تطابق الأصل حرفاً بحرف

التحقّق من digest بلا prefix

نبدأ من «مجرّد digest». تكفي المكتبة القياسيّة في Python 3.

# Python 3.8 以降 / 標準ライブラリのみ
import base64
import hashlib

target = "5f4dcc3b5aa765d61d8327deb882cf99"   # السلسلة المراد تمييزها
plain = b"password"                            # نص واضح معروف

for name in ("md5", "sha1", "sha256", "sha512", "sha3_256", "blake2s"):
    digest = hashlib.new(name, plain).digest()
    if digest.hex() == target.lower():
        print("تطابق hex:", name)
    if base64.b64encode(digest).decode() == target:
        print("تطابق base64:", name)

في هذا المثال يظهر تطابق hex: md5. الشكل الأساسيّ أن تضع في حلقة for الطرق المرشّحة في جدول 2.2 كما هي.

إن أردت تجزئة NT، تكتب شيئاً مثل hashlib.new("md4", "password".encode("utf-16-le"))، لكنّ Python المربوط بـ OpenSSL 3 يعطّل legacy provider افتراضيّاً، وقد تحصل على unsupported hash type md4. تأكّد من بيئتك أوّلاً.

التحقّق من password hash من عائلة crypt

$1$ / $5$ / $6$ / $apr1$ يمكن إعادة حسابها بتمرير salt إلى openssl passwd. أمثلة جدول 2.1 قابلة لإعادة الإنتاج بهذه الطريقة.

# OpenSSL 3.x
openssl passwd -6 -salt N3v8Kx2Lq9Rt password
# $6$N3v8Kx2Lq9Rt$6LUcSUAELX3aC/.60pTB.TFLTQi1mOGRCwKqNCqtRSaXjorxj01HJ9oNni97Kci1uDt7a/Kn4t3OS20Dw/.vi1

openssl passwd -5 -salt N3v8Kx2Lq9Rt password    # sha256crypt
openssl passwd -1 -salt vA7mQ9xZ password        # md5crypt
openssl passwd -apr1 -salt vA7mQ9xZ password     # Apache APR1-MD5

إن طابق المخرج السلسلة قيد التحديد، تثبّت في تلك اللحظة الطريقة والمتن معاً. السلاسل التي تحمل rounds= يلزم تمرير تلك القيمة أيضاً. $6$rounds=5000$... قيمة افتراضيّة، فيطابق الـ digest سواء صرّحت بها أم لا، أمّا قيمة مختلفة عن الافتراضيّ مثل rounds=100000 فيجب الحساب بها حتماً.

على Debian / Ubuntu يمكن فعل الأمر نفسه بـ mkpasswd من حزمة whois (بالشكل mkpasswd -m sha512crypt -S N3v8Kx2Lq9Rt password).

التحقّق من bcrypt وArgon2

في bcrypt وArgon2 يُرمَّز salt بأبجديّة خاصّة، لذا أدقّ أن تمرّر السلسلة كاملة إلى verify في المكتبة بدل قصّها يدوياً.

# pip install "passlib[bcrypt]" argon2-cffi
from passlib.hash import argon2, bcrypt

samples = [
    (bcrypt, "$2b$12$9YQ2u/e5Y/ArOnG.gJKxK.0makLATcYLP1q.Nsabzrw7XErYCfoYO"),
    (argon2, "$argon2id$v=19$m=65536,t=3,p=4$MDEyMzQ1Njc4OWFiY2RlZg$uKZLaN6muIyoyIYr5waqw3y+zaDbe9aLSPj6Ln/rbz4"),
]

for handler, stored in samples:
    # identify はその形式かどうか、verify は平文と一致するかを返します
    print(handler.name, handler.identify(stored), handler.verify("password", stored))

verify يقرأ cost وrounds وsalt من السلسلة ويعيد الحساب، فلا تحتاج إلى استخراج المعاملات بنفسك. مثال bcrypt أعلاه متنه password فيعيد True.

علماً بأنّ وحدة crypt القياسيّة في Python أُهملت وحُذفت في Python 3.13. من 3.13 فصاعداً عالج عائلة crypt عبر openssl passwd أو passlib.

5.4 ترجمة الطريقة المرشّحة إلى رقم hashcat أو اسم john

حين لا يُعرف المتن وتريد التعامل من جهة الأداة، تحتاج إلى الترجمة لا إلى اسم الطريقة بل إلى المعرّف الذي تستعمله الأداة. هنا كثيراً ما يتعثّر الناس، فنضع جدولاً للأشهر.

أرقام الأوضاع تزداد مع الإصدارات، فالطرق الأحدث مثل Argon2 وyescrypt راجعها في قائمة المساعدة على hashcat الذي بين يديك.

John the Ripper يُحدَّد بالاسم لا برقم. ما يفعّله الأصل (1.8.0) هو descrypt، bsdicrypt، md5crypt، bcrypt، LM، AFS، tripcode، dummy، crypt، وكثير ممّا سواها يُضاف في إصدار jumbo. إن لم يكن اسم الطريقة التي تريدها في الأصل، فارجع إلى وثائق jumbo.

ونكرّر: هذه الأدوات تُستعمل فقط على بيئتكم، أو على بيئة صُرِّح لكم بالتحقيق فيها.

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

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

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

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

5.6 الحفظ بعلامة الطريقة من أجل المستقبل

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

• 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
13. MS-NLMP: NTLM v1 Authentication - NTOWFv1(Passwd, User, UserDom) = MD4(UNICODE(Passwd))
14. hashcat wiki - example hashes (قائمة أرقام الأوضاع)
15. John the Ripper - command line options (الأسماء المتاحة بـ --format=NAME)
16. passlib - PasswordHash API (identify و verify)
17. openssl-passwd(1) - -1 / -apr1 / -5 / -6 و -salt

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

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

أين يتصل هذا الموضوع

ترتبط هذه المقالة بشكل طبيعي بصفحات الخدمات التالية.

الأسئلة الشائعة

أسئلة شائعة حول موضوع هذه المقالة.

بأيّ ترتيب أنظر لتمييز طريقة الـ hash من سلسلتها؟

يسهل الترتيب بهذا التسلسل: prefix ثمّ محارف الفصل ثمّ نوع المحارف ثمّ الطول ثمّ السياق. الصيغ التي تحمل معنى في المحارف الأولى سهلة التحديد: $argon2id$ يرجّح Argon2 بقوّة، و$2b$ يرجّح bcrypt، و$5$ هو sha256crypt، و$6$ هو sha512crypt. في المقابل، hex أو Base64 المجرَّد بلا prefix لا يتجاوز تضييق المرشّحين، والحسم النهائيّ يكون بالنظر إلى منتج مصدر الحفظ وإطار العمل والإعدادات.

هل يجوز الجزم بأنّ سلسلة hex بطول 64 خانة هي SHA-256؟

الجزم خطر. SHA-256 مرشّح قويّ، لكنّ الطول نفسه ينتج عن SHA3-256 وSHA-512/256 وBLAKE2s-256 والمخرج الافتراضيّ لـ BLAKE3، فلا يميّزها الطول وحده. الطول مادّة لتكوين مجموعة المرشّحين، لا مادّة للتثبيت. إن لزم الحسم فانظر إلى مواصفات مصدر الحفظ، وصيغة الحفظ في الوثائق الرسميّة، والمطابقة بمتن معروف، ثمّ إلى شيفرة التنفيذ والإعدادات.

هل السلسلة التي تبدأ بـ $6$ هي hash لـ SHA-512؟

لا. $6$ prefix لصيغة حفظ كلمات مرور Unix اسمها sha512crypt. ليست hex digest لـ SHA-512 ذاتها، بل سلسلة password hash تتضمّن salt وrounds. وبالمثل $5$ هو sha256crypt و$1$ هو md5crypt. ما دام الـ prefix موجوداً فالأمر لم يعد «مجرّد digest»، والخلط هنا يُنحرف تنفيذ الترحيل وكود التحقّق.

ماذا يبيّن نوع المحارف؟

نوع المحارف دليل لا يقلّ أهمّيّة عن الطول. إن اقتصرت السلسلة على 0-9a-fA-F فهي تمثيل hex، ونصف عدد المحارف هو طول البايتات الخام. وجود + / = يرجّح Base64 وفق RFC 4648، ووجود - أو _ يرجّح Base64url. إن ظهرت نقطة وشرطة مائلة مع فاصل $، فمن الطبيعيّ الشكّ في alphabet عائلة crypt مثل bcrypt وsha512crypt لا في Base64 العاديّ. معاملة النقطة على أنّها Base64 تالف تُغفل صيغ crypt.

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

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

غو كومورا

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

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