الوحدة 17 · اختبار الأمان

أساسيات التشفير للمختبِرين

بقلم فريق ضمان الجودة في متقن سوفت · · 21 دقيقة · متوسط

علم التشفير (Cryptography) هو مجموعة الأدوات الرياضية التي تحمي البيانات: التجزئة (Hashing) تنتج بصمة ثابتة الطول لا يمكن عكسها، والتشفير (Encryption) يخفي البيانات بحيث لا يقرأها إلا من يملك المفتاح، وHMAC يثبت أن رسالة ما جاءت من طرف يملك سراً مشتركاً ولم تتغيّر في الطريق. أما الترميز (Encoding) مثل Base64 فليس من أدوات الحماية أصلاً، مع أنه يبدو مشابهاً لها؛ فهو يغيّر شكل البيانات فقط، ويستطيع أي شخص عكسه.

مثال: يخزّن نموذج التسجيل كلمة المرور password123 على هيئة cGFzc3dvcmQxMjM=. تبدو القيمة «مشفّرة»، لكنها Base64 فحسب، ويفكّها أي مفكّك ترميز في ثانية واحدة. أما القيمة الصحيحة فهي ناتج دالة تجزئة بطيئة ومملّحة مثل Argon2id، لا يمكن تحويلها إلى كلمة المرور الأصلية مجدداً. والمختبِر الذي يميّز بين الحالتين يكشف عيباً يفوّته كل اختبار وظيفي.

لماذا يهم

يستطيع المنتج أن يفقد كل كلمات المرور أو أرقام البطاقات أو رموز الجلسات مع أن كل ميزة «تعمل»: فيكفي أن تُخزَّن القيم بترميز قابل للعكس أو بتجزئة سريعة بلا ملح، أو أن يُقبل Webhook مزوّر لأن أحداً لم يتحقق من توقيعه. وتجمع قائمة OWASP Top 10 هذه الحالات تحت A04:2025 «إخفاقات التشفير» (Cryptographic Failures)، ولا تكشفها الاختبارات الوظيفية لأن مسار المستخدم نفسه ينجح.

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

الترميز والتجزئة والتشفير ثلاثة أشياء مختلفة

الترميز (Encoding) يغيّر تمثيل البيانات بقاعدة معلنة لا سرّ فيها. فـBase64 (RFC 4648) يحوّل كل ⁦3⁩ بايتات إلى ⁦4⁩ أحرف من أبجدية تضم ⁦64⁩ حرفاً، ويُكمل نهاية الناتج بعلامة = عند الحاجة؛ والترميز السداسي العشري (Hex) يكتب كل بايت برقمَين. غرضه نقل البايتات بأمان داخل نص أو عنوان URL أو ترويسة HTTP، كما فعلت ترويسة Authorization من نوع Basic في درسَي ترويسات HTTP والمصادقة والتفويض. ومن يملك الناتج يملك المدخل.

التجزئة (Hashing) تحوّل أي مدخل إلى بصمة ثابتة الطول: ⁦64⁩ حرفاً سداسياً عشرياً في SHA-256، و⁦40⁩ في SHA-1، و⁦32⁩ في MD5. المدخل نفسه يعطي البصمة نفسها دائماً، ولا يمكن استعادة المدخل من البصمة، وتغيير حرف واحد يغيّر البصمة كلها. تستخدمها الأنظمة للتحقق من سلامة الملفات ولمقارنة البيانات دون تخزينها. ولا يجوز استخدام MD5 وSHA-1 حيث يعتمد الأمان عليهما، إذ نُشرت لكلٍّ منهما طرق عملية لإنتاج مدخلَين مختلفَين لهما البصمة نفسها (وهو ما يسمّى التصادم، Collision).

التشفير (Encryption) يخفي البيانات بحيث لا يمكن استعادتها إلا بمفتاح. في التشفير المتماثل (مثل AES) يُستخدم المفتاح نفسه للتشفير وفك التشفير؛ وفي التشفير غير المتماثل (مثل RSA والمنحنيات الإهليلجية) يوجد زوج مفاتيح: ما يُشفَّر بالمفتاح العام يُفكّ بالمفتاح الخاص وحده. ويستخدم TLS النوعَين معاً: غير المتماثل للتعريف بالخادم والاتفاق على المفاتيح، والمتماثل لتشفير البيانات نفسها. والسؤال الذي يميّز الثلاثة هو: هل يمكن عكسه؟ ومن يملك ما يلزم لعكسه؟

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

الترميزBase64 · RFC 4648

يغيّر طريقة كتابة البايتات بقاعدة معلنة لا سرّ فيها

cGFzc3dvcmQxMjM=

يحتاج إلى مفتاح:
لا
قابل للعكس:
نعم، لأي شخص
ما يحميه:
لا شيء: للنقل فقط
أين تقابله:
ترويسة Basic، أجزاء JWT، عناوين data
ما يسأله المختبِر:
هل يُعامَل كأنه حماية؟

التجزئةSHA-256 · FIPS 180-4

بصمة ثابتة الطول للمدخل؛ والمدخل نفسه يعطي البصمة نفسها دائماً

ef92b778bafe771e…

يحتاج إلى مفتاح:
لا
قابل للعكس:
لا
ما يحميه:
السلامة: أي تغيير يظهر
أين تقابله:
مجاميع التحقق للملفات، معرّفات الإيداعات، البصمات
ما يسأله المختبِر:
هل هي MD5 أو SHA-1؟ وهل تُستخدم لكلمات المرور بلا ملح وعامل كلفة؟

HMACRFC 2104

تجزئة تُحسب بمفتاح سرّي مشترك

2b46560cfc07e738…

يحتاج إلى مفتاح:
نعم، مشترك بين الطرفَين
قابل للعكس:
لا
ما يحميه:
السلامة والمصدر
أين تقابله:
توقيعات Webhook، رموز JWT بخوارزمية HS256، الكوكيز الموقّعة
ما يسأله المختبِر:
هل يُرفض التوقيع الخاطئ والمفقود؟ وهل تُعالَج إعادة الإرسال؟

التشفيرAES · RSA · TLS

يخفي البيانات؛ والنص المشفّر يختلف في كل مرة ولا يستعيده إلا المفتاح

يحتاج إلى مفتاح:
نعم: مفتاح مشترك واحد، أو زوج عام وخاص
قابل للعكس:
نعم، بالمفتاح
ما يحميه:
السرية
أين تقابله:
TLS، البيانات المخزّنة، النسخ الاحتياطية المشفّرة
ما يسأله المختبِر:
من يملك المفتاح؟ وأيّ إصدارات TLS؟ وكيف يُدوَّر المفتاح؟

القيم هي النواتج الحقيقية لـBase64 وSHA-256 وHMAC-SHA256 للمدخل password123 مع مفتاح الاختبار test-secret؛ والبصمتان مختصرتان.

النسخة النصية
Input: password123

Encoding    Base64       cGFzc3dvcmQxMjM=
                         anyone can decode it: no key, no secret
Hashing     SHA-256      ef92b778bafe771e89245b89ecbc08a44a4e166c06659911881f383d4473e94f
                         one way, fixed length, same input -> same output
            MD5 (legacy) 482c811da5d5b4bc6d497ffa98491e38
                         32 hex characters; not for anything security-related
HMAC        HMAC-SHA256  2b46560cfc07e738b1b40765b282308026cdd5b9d2aae58be8a347b1293a82e7
                         key: test-secret; only a key holder can compute or check it
Encryption  AES-256-GCM  <ciphertext + nonce>, different on every run
                         reversible only with the key

جرّبها: مفكّك ترميز Base64 جرّبها: مولّد SHA-256 جرّبها: مولّد MD5

HMAC والتوقيعات: تجزئة بمفتاح تثبت المصدر

التجزئة وحدها تكشف التغيير لكنها لا تثبت المصدر: فمن يعدّل الرسالة يستطيع حساب بصمتها الجديدة أيضاً. يعالج HMAC (RFC 2104) ذلك بإدخال مفتاح سرّي في الحساب: HMAC-SHA256(key, message). ولا يستطيع إنتاج القيمة الصحيحة أو التحقق منها إلا من يملك المفتاح، فتثبت القيمة أمرَين معاً: أن الرسالة لم تتغيّر، وأنها جاءت من طرف يملك السر. ولا يخفي HMAC محتوى الرسالة؛ فهو ليس تشفيراً.

ستقابله في توقيعات Webhook (ترويسة مثل X-Signature-256)، وفي رموز JWT الموقّعة بخوارزمية HS256 (وهي HMAC-SHA256)، وفي الروابط والكوكيز الموقّعة. أما التوقيع الرقمي (مثل RS256 وES256) فيؤدي الغرض نفسه بمفاتيح غير متماثلة: يوقّع المفتاح الخاص ويتحقق المفتاح العام، فلا يحتاج المتحقق إلى سر. وفي الحالتَين، فكّ ترميز الرمز شيء والتحقق من توقيعه شيء آخر، كما يوضّح دليل JWT.

  • الجسم نفسه مع توقيع صحيح: يُقبل. غيّر حرفاً واحداً في الجسم وأبقِ التوقيع كما هو: يجب أن يُرفض.
  • توقيع محسوب بسرّ خاطئ، أو ترويسة توقيع مفقودة أصلاً: يجب أن يُرفض كلاهما؛ فالخادم الذي يقبل الطلب من دون الترويسة لا يتحقق أصلاً.
  • إعادة إرسال طلب قديم صحيح: HMAC وحده لا يمنعها. اسأل هل يدخل طابع زمني في المادة الموقّعة، وهل يُرفض القديم منها.
  • اسأل المطور كيف تُقارَن القيمتان؛ فالتوصية المعتادة هي المقارنة ثابتة الزمن (Constant-time)، التي تستغرق الوقت نفسه مهما كان عدد الأحرف المتطابقة، فلا يكشف زمن الاستجابة شيئاً عن أي تخمين. وهذا مما لا يُرى من الخارج.
Partner -> your server

POST /webhooks/payments HTTP/1.1
Host: shop.example.com
Content-Type: application/json
X-Signature-256: sha256=ff40b419851351c2ed7966278bc1d026ecbac717fbbbfebfb068715b3860c4d7

{"event":"order.paid","orderId":"ORD-1042","amount":"249.00"}

Check on your server: HMAC-SHA256(secret, raw body) == the value after "sha256="?
  yes -> process the event      no -> reject it (for example with 401)
Secret for this example: whsec_test_key. Change one byte of the body, or the secret,
and the computed value no longer matches.

جرّبها: مولّد HMAC جرّبها: محلّل توقيعات Webhook

تجزئة كلمات المرور حالة خاصة

كلمات المرور مدخلات ضعيفة: فهي قصيرة ومتوقعة ويكررها الناس. لذلك لا تكفي دالة تجزئة سريعة مثل SHA-256، لأن المهاجم الذي يحصل على قاعدة البيانات يستطيع حساب بصمات مليارات كلمات المرور الشائعة ومقارنتها. والحل من جزأَين: ملح (Salt) عشوائي مختلف لكل مستخدم، فلا تتشابه القيمتان المخزّنتان لمستخدمَين اختارا الكلمة نفسها ولا تنفع الجداول المحسوبة مسبقاً؛ ودالة مصممة لتكون بطيئة عمداً، ومكلفة في الذاكرة أيضاً في Argon2id وscrypt: يتحمّل تأخيرها تسجيل دخول واحد ولا يتحمّله مليار محاولة تخمين.

توصي ورقة OWASP الإرشادية لتخزين كلمات المرور (Password Storage Cheat Sheet) بـArgon2id أولاً، ثم scrypt، وbcrypt للأنظمة القديمة، وPBKDF2 حيث يُشترط الامتثال لمعيار ⁦FIPS-140⁩ (معيار حكومي أمريكي لوحدات التشفير). وتولّد هذه الخوارزميات الملح بنفسها وتخزّنه داخل القيمة، بجانب اسم الخوارزمية ومعاملاتها؛ فالملح ليس سراً، ووظيفته الوحيدة أن يجعل كل قيمة مخزّنة فريدة. لذلك يمكنك التعرّف على هذه القيم من شكلها كما في المثال.

  • أنشئ حسابَين بكلمة المرور نفسها: القيمتان المخزّنتان يجب أن تختلفا (ملح لكل مستخدم).
  • استعادة كلمة المرور: يجب أن يصل رابط إعادة تعيين، لا كلمة المرور الحالية أبداً؛ فالنظام الذي يستطيع إرسالها يخزّنها بصورة قابلة للعكس.
  • إذا كانت bcrypt، فتذكّر أنها تهمل كل ما بعد ⁦72⁩ بايتاً: ضع كلمة مرور من ⁦80⁩ حرفاً، ثم سجّل الدخول بعد تغيير الحرف الأخير. فإن نجح الدخول، فاسأل عن حدّ الطول.
  • انظر إلى القيمة لا إلى الاسم: عمود باسم password_hash قد يحوي Base64 أو MD5.
Two users, both chose password123

Unsalted SHA-256 (defect): identical values, and easy to look up in precomputed tables
  user A  ef92b778bafe771e89245b89ecbc08a44a4e166c06659911881f383d4473e94f
  user B  ef92b778bafe771e89245b89ecbc08a44a4e166c06659911881f383d4473e94f

Argon2id (accepted): algorithm, parameters, random salt and hash; different per user
  user A  $argon2id$v=19$m=19456,t=2,p=1$<salt A>$<hash A>
  user B  $argon2id$v=19$m=19456,t=2,p=1$<salt B>$<hash B>

bcrypt (accepted): $2b$<cost>$<22-character salt><31-character hash>, 60 characters

TLS والمفاتيح: حيث تلتقي الأدوات بالنظام

شرح درس HTTP وHTTPS المصافحة والشهادات وسلسلة الثقة. ومن زاوية هذا الدرس، TLS (RFC 8446 للإصدار 1.3) هو أكثر المواضع شيوعاً التي تعمل فيها هذه الأدوات معاً: شهادة وتوقيع رقمي للتعريف بالخادم، وتشفير غير متماثل للاتفاق على المفاتيح، وتجزئة وHMAC لاشتقاق تلك المفاتيح وتأكيد المصافحة، ثم تشفير متماثل مع فحص سلامة لكل بايت يمرّ. لذلك فإن كل كلمة مرور ورمز ورقم بطاقة يُرسل عبر HTTP صريح ينتقل من دون أي من هذه الحمايات.

  • الإصدارات المقبولة: TLS 1.2 و1.3 فقط؛ فالإصدارات الأقدم وSSL كلها مهملة. تحقق من ذلك على كل بيئة، لا على الإنتاج وحده. تعرض أداة «مختبِر نقاط نهاية API» حالة TLS وHSTS لنقطة نهاية عامة؛ أما سرد كل الإصدارات التي ما زال الخادم يقبلها فيحتاج إلى ماسح TLS مثل nmap --script ssl-enum-ciphers -p 443 <host>، ولا يُشغَّل إلا على خوادم لديك إذن باختبارها.
  • كل منفذ دخول: واجهة API، وتطبيق الويب، وتطبيق الجوال، وWebhook الذي يرسله خادمك إلى شريك، والاتصالات الداخلية بين الخدمات، لا الصفحة الرئيسية فقط.
  • عملاء الاختبار يتحققون من الشهادات كما يفعل المستخدمون الحقيقيون؛ وإطفاء التحقق «مؤقتاً» عيب في إعداد الاختبار نفسه.
  • المفاتيح والأسرار: المفتاح المضمَّن في حزمة الواجهة أو تطبيق الجوال مفتاح عام فعلياً؛ والسر المُنشأ بـMath.random() ليس عشوائياً بما يكفي؛ واسأل كيف يُدوَّر المفتاح عند تسرّبه.
  • ماذا تعني «مشفّرة أثناء التخزين» هنا؟ اسأل من يملك المفتاح: فإن كان خادم التطبيق يستطيع فكّ كل شيء، فكذلك كل من يخترقه.

جرّبها: مختبِر نقاط نهاية API

مثال تطبيقي: مراجعة ميزة الدفع وWebhook

تختبر ميزة جديدة: ينشئ العميل حساباً، ويحفظ بطاقة، ويُخطر شريك الدفع خادمك بكل عملية دفع عبر Webhook. وفي مراجعة التصميم والبيانات تلاحظ أربع قيم:

  • users.password يحوي cGFzc3dvcmQxMjM=: Base64، أي كلمة مرور صريحة لكل من يقرأ قاعدة البيانات. عيب؛ أرفق القيمة المفكوكة من بيئة الاختبار، ولا ترفق كلمة مرور مستخدم حقيقي أبداً.
  • cards.pan_masked يعرض **** 4242، لكن استجابة /profile تحمل cardRef بـBase64 يُفكّ إلى رقم البطاقة كاملاً. عيب في كشف البيانات الحساسة، وسببه الجذري الخلط بين الترميز والتشفير.
  • يحمل Webhook ترويسة X-Signature-256، لكن الطلب نفسه من دون الترويسة يُقبل بالرمز 200. الخادم لا يتحقق؛ ويستطيع كل من يعرف العنوان أن يعلن «تم الدفع». عيب.
  • فحص TLS على api-staging يُظهر قبول TLS 1.0. ملاحظة لفريق المنصة، مع سؤال: هل الإنتاج مضبوط بالطريقة نفسها؟

أخطاء شائعة

  • معاملة Base64 أو Hex أو ترميز URL كأنها حماية: «رقم البطاقة مرمّز» تعني أنه مقروء.
  • كتابة «مشفّر» في تقرير خطأ أو متطلب والمقصود «مجزّأ»، أو طلب «فك تشفير» بصمة من المطورين: الكلمة الخاطئة تقود إلى إصلاح خاطئ.
  • قبول عبارة «كلمات المرور مجزّأة» من دون السؤال عن الخوارزمية وعن وجود ملح؛ فـSHA-256 وحدها عيب في تخزين كلمات المرور.
  • فكّ ترميز JWT أو Webhook وفحص محتواه ثم الوثوق به من دون التحقق من التوقيع، أو اختبار التوقيع في المسار السعيد فقط من دون إرسال توقيع خاطئ قط.
  • الحكم على القيمة من مظهرها: سلسلة عشوائية المظهر من ⁦64⁩ حرفاً قد تكون SHA-256 بلا ملح لكلمة مرور، أو معرّفاً متوقعاً مرمّزاً.
  • محاولة كسر الخوارزميات نفسها، أو المحاولة على أنظمة لا تملكها: المختبِر يتحقق من أن الأداة الصحيحة استُخدمت بالطريقة الصحيحة، وعلى أنظمة لديه إذن كتابي باختبارها.

من منظور ضمان الجودة

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

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

تمرين عملي

صنّف القيم وقرّر ما تختبره

المطلوب

أثناء اختبار بيئة Staging لتطبيق متجر رأيت القيم الخمس أدناه في تصدير قاعدة البيانات وفي الطلبات. حدّد لكل قيمة: هل هي ترميز أم تجزئة أم HMAC أم تشفير أم إعداد TLS؟ وهل تناسب غرضها؟ وما الاختبار أو السؤال التالي؟

استعن بأدوات مُتقن حيث تفيد: مفكّك ترميز Base64، ومولّدَي MD5 وSHA-256، ومحلّل توقيعات Webhook، ولا تعمل إلا ببيانات اختبار.

المادة
1. users.password            cGFzc3dvcmQxMjM=
2. legacy_users.pwd          482c811da5d5b4bc6d497ffa98491e38
3. users.password_hash       $2b$12$<22-character salt><31-character hash>
4. incoming webhook header   X-Signature-256: sha256=<64 hex characters>
5. api-staging.example.com   TLS check: accepts TLS 1.0, 1.2 and 1.3
الخطوات
  1. انظر إلى الشكل: الطول، والأبجدية، والبادئة، وعلامة = في النهاية.
  2. قرّر: هل يمكن عكسها؟ وهل تحتاج إلى مفتاح؟
  3. قارن ذلك بالغرض الذي تُستخدم له.
  4. اكتب الاختبار أو السؤال الذي يثبت العيب أو ينفيه.
إظهار الإجابة النموذجية
الإجابة النموذجية

القيمة ⁦1⁩: Base64 (تنتهي بـ=، وتُفكّ إلى password123). كلمة المرور مخزّنة بصورة قابلة للعكس، أي كأنها نص صريح. عيب؛ الاختبار هو أن تفكّها بنفسك، ويذكر التقرير العمود وأن كل من يقرأ قاعدة البيانات يملك كلمات المرور جميعها.

القيمة ⁦2⁩: ⁦32⁩ حرفاً سداسياً عشرياً، وهو طول بصمة MD5. وإذا جزّأت password123 (كلمة المرور المفكوكة من القيمة ⁦1⁩) بمولّد MD5 حصلت على هذه القيمة نفسها بالضبط: إنها MD5 بلا ملح. عيب: دالة سريعة ومهملة بلا ملح، فكل من اختار كلمة المرور نفسها من المستخدمين له القيمة نفسها. والطول وحده يرجّح MD5 فقط، أما التطابق مع كلمة مرور معروفة فيثبته.

القيمة ⁦3⁩: bcrypt بعامل كلفة ⁦12⁩، وهي مقبولة (تطلب OWASP عامل كلفة ⁦10⁩ فأكثر). الاختبارات: حسابان بالكلمة نفسها يعطيان قيمتَين مختلفتَين؛ واستعادة كلمة المرور ترسل رابطاً لا كلمة مرور؛ وكلمة مرور من ⁦80⁩ حرفاً يجب ألا تدخل بعد تغيير حرفها الأخير، وإلا فاسأل عن حدّ ⁦72⁩ بايتاً.

القيمة ⁦4⁩: ⁦64⁩ حرفاً سداسياً عشرياً بعد sha256= تناسب HMAC-SHA256، لكنها تناسب أيضاً SHA-256 عادية للجسم؛ فالشكل وحده لا يميّز بينهما. احسب SHA-256 لجسم طلب ملتقَط كما هو: فإن ساوى القيمة، فلا مفتاح ويستطيع أي شخص تزويرها (عيب). وإن أكّد محلّل توقيعات Webhook أنها HMAC-SHA256 بسرّ الاختبار، فالتصميم صحيح؛ ثم اختبر أن الجسم المغيَّر بحرف واحد والسرّ الخاطئ والترويسة المفقودة تُرفض كلها، واسأل هل يمنع طابع زمني إعادة إرسال طلب قديم صحيح.

القيمة ⁦5⁩: إعداد TLS لا خوارزمية؛ وقبول TLS 1.0 ملاحظة لفريق المنصة: المسموح 1.2 و1.3 فقط. اسأل هل للإنتاج الإعداد نفسه، وأكمل فحص الشهادة وإعادة التوجيه من HTTP إلى HTTPS كما في درس HTTP وHTTPS.

أسئلة شائعة

هل التجزئة نوع من التشفير؟

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

كلمات المرور لدينا مجزّأة بـSHA-256. هل هذا كافٍ؟

لا. SHA-256 سريعة جداً، ومن دون ملح تعطي القيمة نفسها لكل مستخدم اختار الكلمة نفسها. يحتاج تخزين كلمات المرور إلى خوارزمية مخصصة بطيئة ومملّحة: Argon2id أولاً، أو scrypt أو bcrypt، أو PBKDF2 حيث يُشترط الامتثال لمعيار FIPS.

هل أستطيع التحقق من توقيع Webhook أو JWT من دون السر؟

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

هل أحتاج إلى فهم الرياضيات وراء هذه الخوارزميات؟

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

المراجع

الأدوات

تدرّب بأدوات متقن

مولّد SHA-256

توليد تجزئات SHA-256 للنصوص — المعيار الأساسي لفحوصات السلامة والتوقيعات.

الأمان

مولّد MD5

توليد تجزئات MD5 للنصوص في متصفحك (للمجاميع الاختبارية والمقارنات مع الأنظمة القديمة).

الأمان

مولّد HMAC

توليد توقيعات HMAC (SHA-256/384/512/SHA-1) لتوقيع طلبات webhook وواجهات API.

الأمان

محلّل توقيعات Webhook

تحقّق من توقيعات webhook (بأنظمة HMAC-SHA256/SHA1 وStripe وGitHub وShopify وSlack) باستخدام سرّك — محلياً.

اختبار واجهات API

مفكّك ترميز Base64

فكّ ترميز سلاسل Base64 أو Base64url إلى نص، مع إصلاح الحشو تلقائياً.

الترميز

مختبِر نقاط نهاية API

تحقّق سريعاً من إمكانية الوصول إلى نقطة نهاية API: الحالة وزمن الاستجابة والحجم ونوع المحتوى وTLS.

اختبار واجهات API

للتعمّق أكثر

تقدّمك في هذا الموضوع

جزء من مسار تعلم ضمان الجودة

الموضوعات التالية