الترميز والهاش والتشفير ثلاثة أشياء مختلفة
يكاد كل سوء فهم في هذه الصفحة ينبع من معاملة هذه الثلاثة كأنها متبادلة، لذا يستحق الأمر الفصل بينها كما ينبغي.
الترميز قابل للعكس ولا سرّ فيه. وُجد Base64 لنقل البيانات الثنائية عبر قنوات لا تقبل إلا النص — مرفقات البريد الإلكتروني، وروابط data URI، وسلاسل JSON — بتمثيل كل ثلاثة بايتات بأربعة أحرف، ولهذا تأتي النتيجة دائمًا أكبر بنحو الثلث. لا يوجد مفتاح. ويستطيع أي شخص يرى السلسلة فك ترميزها بخطوة واحدة، بما في ذلك على هذا الموقع. Base64 ليس أمانًا، ولا تمويهًا يستحق هذا الاسم، ولا وسيلة لإخفاء أي شيء عن أي شخص ينظر. والترميز بالنسبة المئوية (percent-encoding) من النوع نفسه لكن لروابط URL، وفيه يكمن الخطأ الشائع الآخر: ترميز قيمة واحدة تدخل في سلسلة الاستعلام عملية مختلفة عن تنظيف رابط URL كامل مُجمَّع، لأن الأولى وحدها تهرّب الرموز & و= و? و/ التي تمنح الرابط بنيته. وإن أخطأت، يصل «Smith & Sons» إلى الخادم كمعاملين بدل قيمة واحدة.
الهاش أحادي الاتجاه ولا مفتاح له أيضًا. تأخذ دالة الهاش أي مدخل وتنتج بصمة بطول ثابت، ولا تراجع عنها — لا لأنها مشفّرة، بل لأن المعلومات ضاعت. ما يمكنك فعله هو تخمين المدخلات والمقارنة، وهذا بالضبط ما يجعل MD5 وSHA-1 وSHA-256 خيارًا خاطئًا لتخزين كلمات المرور: فهي سريعة، وبطاقة الرسومات تحسب منها مليارات في الثانية، وجدول مسروق منها يُكسر بتلك السرعة. كلمات المرور تحتاج إلى دالة بطيئة عمدًا ومملّحة (salted) — bcrypt أو scrypt أو Argon2. وبشكل منفصل، MD5 وSHA-1 مكسوران لسبب آخر: يمكن الآن تصميم ملفين مختلفين لهما الهاش نفسه عمدًا، لذا لا يستطيع أيٌّ منهما إثبات أن الملف هو الملف الذي توقعته، وإن ظلّا صالحين لاكتشاف ملف منزّل تلف عن غير قصد.
التشفير هو الوحيد الذي له مفتاح، ولا تقوم به أي من هذه الأدوات. وهذا ليس سهوًا. فالتشفير الصحيح يتطلب إدارة المفاتيح، وصفحة الويب هي المكان الخطأ للمفتاح.
رمز JWT موقَّع لا مشفّر، وهذا يوقع الناس في الخطأ باستمرار. ترويسة الرمز وحمولته بترميز Base64URL — يقرؤهما أي شخص يملك الرمز، دون الحاجة إلى مفتاح. التوقيع يمنع أي شخص من تغيير الرمز؛ لكنه لا يفعل شيئًا لمنعه من قراءته، لذا لا مكان لأي شيء سري في الحمولة. ويترتب على ذلك أن فك ترميز رمز لا يثبت عنه أي شيء على الإطلاق: يستطيع أي شخص كتابة ما يشاء من الادعاءات وترميزها بـ Base64. التحقق يعني إعادة حساب التوقيع بمفتاح الجهة المُصدِرة، وهذا أمر يقوم به خادمك ولا يجوز أبدًا لموقع ويب أن يطلبه. لذلك يرفض فك الترميز لدينا الإيحاء بأنه تحقق، وينبّه إلى الأنماط التي تدل على مشكلة — رمز منتهي الصلاحية، ورمز بلا تاريخ انتهاء إطلاقًا، وخوارزمية «none»، وهي ثغرة موثّقة لتجاوز المصادقة لا مجرد غرابة.
في JSON حدّ لدقة الأرقام تقع فيه معظم أدوات التنسيق بصمت. لا يضع JSON نفسه أي حد لحجم الرقم، لكن الرقم في JavaScript عدد عشري بحجم 64 بت، لذا تبقى الأعداد الصحيحة دقيقة فقط حتى 9,007,199,254,740,991. ومعرّف منشور على Twitter، أو معرّف Discord من نوع snowflake، أو مفتاح قاعدة بيانات بحجم 64 بت، أو رقم حساب مصرفي، كلها أكبر من ذلك، وتمريرها عبر أداة التنسيق المعتادة ذات السطر الواحد — تحليل ثم تحويل إلى نص — يغيّر أرقامها الأخيرة. وتظل النتيجة تبدو رقمًا معقولًا، وهذا ما يجعلها خطيرة: 7205759403792793600 يصبح بهدوء 7205759403792793000. تعيد أدوات JSON لدينا كتابة الأرقام الدقيقة التي لصقتها كما هي، وتخبرك بعدد الأرقام التي اضطرت إلى حمايتها.
إصدار UUID يصف طريقة إنشائه، لا ما يضمنه. لا شيء يسجّل معرّفات UUID أو يفرض تفرّدها؛ فالتفرّد احتمالي، والإصدار يخبرك من أين جاءت البتات. الإصدار 4 هو 122 بتًا من العشوائية من المولّد التشفيري في المتصفح، ما يجعله غير قابل للتخمين، ومن ثم مناسبًا لروابط إعادة التعيين ورموز الدعوة وأي شيء سري — وغير مناسب كمفتاح لقاعدة بيانات، لأن المفاتيح العشوائية تتبعثر في الفهرس المرتّب وتجزّئه. أما الإصدار 7 فيضع في بدايته طابعًا زمنيًا بالمللي ثانية بحجم 48 بت، فتُضاف المفاتيح إلى نهاية الفهرس كعدد صحيح متزايد تلقائيًا مع بقائها فريدة عالميًا. والمقابل أن UUID من الإصدار 7 يكشف بوضوح وقت إنشائه، حتى المللي ثانية، لأي شخص يملكه.
متى يكون المتصفح الأداة الخطأ فعلًا
لا ترسل أي من هذه الأدوات الثلاث عشرة أي شيء إلى أي مكان. لا يُرسَل أي طلب، ولا يُسجَّل أي شيء، وتظل الصفحات تعمل مع قطع الاتصال بالشبكة — ولهذا تحديدًا يمكن استخدامها مع استجابة API مليئة بسجلات العملاء أو رمز مميز لن ترسله بالبريد إلى أحد. هذه هي الحجة الصادقة لصالحها. وإليك الحجة الصادقة ضدها.
لصق سرّ إنتاجي فعّال في صفحة ويب عادة يُستحسن تجنبها — بما في ذلك هذه الصفحة. ادعاؤنا بشأن الخصوصية صحيح، لكن الادعاء ليس ما يحميك؛ ما يحميك هو سلوك الشيفرة، والموقف المعقول الوحيد تجاه أي صفحة ويب هو التحقق لا الثقة. والتحقق لا يكلّف شيئًا: اقطع الاتصال بالإنترنت بعد تحميل الصفحة وراقب هذه الأدوات وهي تواصل العمل. الأداة التي تحتاج إلى خادم ستتوقف. وإذا كانت بيانات الاعتماد لا تزال صالحة وقد لصقتها بالفعل في مكان لا يمكنك تدقيقه، فالخطوة الصحيحة هي تغييرها، لا التفكير في الأمر. ولرمز فعّال الآن، فك ترميزه محليًا — بدالة Base64 في لغة البرمجة التي تستخدمها، أو بسطرين في سطر الأوامر — ممارسة أفضل من أي موقع ويب، بما فيه موقعنا.
التحقق من المخطط (schema). تتحقق أدوات JSON وXML لدينا من أن المستند سليم البنية، وهذا سؤال مختلف عن مطابقته لمخطط. فالتحقق وفق JSON Schema أو XSD يعني جلب ملف مخطط وتطبيقه، وهذا طلب شبكة لا تقوم به هذه الصفحات عمدًا أبدًا. استخدم ajv لـ JSON Schema وxmllint لـ XSD وDTD؛ كلاهما مجاني وكلاهما أفضل في ذلك مما يمكن أن تكونه صفحة ويب.
أي شيء كبير فعلًا، أو يُعالَج تدفقيًا. تُحفظ المستندات كاملة في الذاكرة، وأحيانًا مرتين أثناء التنسيق، لذا فالحد الأقصى هو علامة التبويب. بضعة ميغابايتات تتم فورًا، وبضع مئات ليست كذلك. أداة jq تعالج تدفقيًا ملف JSON بعدة غيغابايتات لن يفتحه أي متصفح، وripgrep يبحث في مستودع كامل أسرع مما تلصق ملفًا واحدًا. وللهاش صورة أشد من الحد نفسه: التشفير في المتصفح لا يوفّر حسابًا تدريجيًا للهاش، لذا يجب أن يتسع الملف كله في الذاكرة دفعة واحدة — وستفشل صورة قرص DVD، بينما تعالجها sha256sum أو shasum أو certutil تدفقيًا دون أن تلاحظ.
الأتمتة وCI. تعمل هذه الأدوات عندما ينقر شخص ما. أما تنسيق كل ملف في مستودع، أو توليد عشرة آلاف UUID في ملف بيانات اختبار، أو فحص JSON ضمن خط إنتاج، فمكانها سكربت: jq وxmllint وuuidgen وopenssl وأمر base64 مثبّتة مسبقًا على معظم الأجهزة.
التحقق من أي شيء موقَّع. التحقق من التوقيعات وسلاسل الشهادات وأي شيء يتطلب مفتاحًا خاصًا يجب أن يتم على خادمك بمكتبة تخضع للصيانة. ستخبرك هذه الصفحة بما يدّعيه الرمز؛ ولن تخبرك أبدًا بأن الرمز أصلي، وعليك ألا تثق بأي موقع يقول إنه يستطيع ذلك دون مفتاحك.
الاختيار بين الأدوات المتشابهة في أسمائها
تنسيق JSON أم التحقق من JSON. المحلّل نفسه، والسؤال مختلف. أداة التنسيق لقراءة مستند يُحلَّل بالفعل وإعادة تشكيله — إضافة المسافات البادئة، أو تصغيره، مع الحفاظ على الأرقام الكبيرة سليمة. أما أداة التحقق فلمستند يتعذر تحليله، ونتيجتها هي السطر والعمود والحرف المسبب للخطأ مع علامة ^ تحته، وأي الأسباب الأربعة المعتادة كان السبب. إذا كنت تحدّق في «Unexpected token»، فأنت تحتاج إلى أداة التحقق. والتقسيم نفسه ينطبق على «تنسيق XML» و«التحقق من XML».
فك ترميز Base64 أم فك ترميز JWT. رمز JWT ثلاثة أقسام بترميز Base64URL، لذا ستعرض لك أداة فك الترميز العامة الأجزاء. أما صفحة JWT فتفصلها لك، وتنسّق JSON، وتحوّل ادعاءات انتهاء الصلاحية ووقت الإصدار وعدم الصلاحية قبل (not-before) من طوابع Unix الزمنية إلى تواريخ حقيقية بمنطقتك الزمنية، وتسمّي الادعاءات المسجّلة، وتنبّه إلى انتهاء الصلاحية وإلى خوارزمية «none». استخدم أداة فك الترميز العامة لكتلة Base64، وصفحة JWT للرمز المميز.
ترميز Base64 أم ترميز URL. مهمتان مختلفتان تنتج كلتاهما نصًا «آمنًا». Base64 يحوّل بايتات عشوائية إلى نص مقابل زيادة في الحجم بنسبة 33 بالمئة، وBase64 القياسي ليس آمنًا في رابط URL إطلاقًا — فالرموز + و/ و= كلها تعني شيئًا هناك، ولهذا وُجد Base64URL. أما الترميز بالنسبة المئوية فيترك النص المقروء مقروءًا ولا يهرّب إلا ما قد يعطّل الرابط، وهذا ما تريده لعبارة بحث أو عنوان بريد إلكتروني أو وجهة إعادة توجيه. وترميز ملف كامل لوضعه في سلسلة استعلام علامة في الغالب على أنه كان يجب أن يكون في متن الطلب.
مولّد الهاش أم مولّد UUID. الهاش مشتق من مدخله، لذا يعطي المدخل نفسه القيمة نفسها دائمًا — وهذا ما يجعله بصمة، مفيدة للتحقق من ملف منزّل أو لإزالة المحتوى المتطابق المكرر. أما UUID فعشوائية جديدة لا علاقة لها بأي شيء، لذا لا يتكرر أبدًا. إذا أردت المعرّف نفسه للمحتوى نفسه، فاحسب الهاش. وإذا أردت معرّفًا جديدًا، فأنشئ UUID.
إنشاء رمز QR أم إنشاء باركود. رمز QR شبكة ثنائية الأبعاد تحمل أي نص — رابط URL، أو بيانات اتصال Wi-Fi، أو رقم هاتف — وتقرؤه كاميرا الهاتف. أما صفحة الباركود فتنشئ رموز البيع بالتجزئة واللوجستيات أحادية البعد: EAN-13 وEAN-8 وUPC-A وITF-14 وCode 128 وCode 39، مع حساب رقم التحقق الخاص بالبيع بالتجزئة ورفض الرقم الخاطئ أو الناقص بدل إكماله بصمت إلى باركود صالح لمنتج آخر.