كل مطور قام بدمج واجهة برمجة تطبيقات تابعة لجهة خارجية قد اصطدم بنفس الجدار: المستندات تقول "؛ المصادقة باستخدام المصادقة الأساسية، "؛ تقوم بلصق مفتاحك وسرك في الطلب، ويجيب الخادم بشقة 401 Unauthorized ولا يوجد تلميح حول السبب. تم ترميز بيانات الاعتماد تسع مرات من أصل عشرة بشكل خاطئ بعض الشيء، ولا يوجد شيء في الخطأ يخبرك بذلك. لقد قمت ببناء واستهلاك ما يكفي من واجهات برمجة التطبيقات عبر مكونات WordPress الإضافية وواجهات Laravel الخلفية لإضاعة قدر محرج من الوقت في هذا بالضبط، لذلك وضعت مولد المصادقة الأساسية على تولز.ديف يؤدي ذلك إلى إنشاء الرأس بشكل صحيح في كل مرة وفك تشفيره مرة أخرى عندما تحتاج إلى التحقق. هذا هو الدليل له وللمخطط الذي يقف وراءه.
ليرة تركية؛DR: ترسل مصادقة HTTP الأساسية اسم مستخدم وكلمة مرور كـ
base64(username:password)في الAuthorizationرأس. الأدوات مولد المصادقة الأساسية يحول اسم المستخدم وكلمة المرور إلى الرأس الدقيق، وأمر تجعيد جاهز للتشغيل، ومقتطف جلب، ونموذج معلومات مستخدم URL، ويقوم بفك تشفير الرموز المميزة الموجودة مرة أخرى. يقوم بالتشفير عبر UTF-8 حتى تبقى بيانات الاعتماد غير ASCII على قيد الحياة، ويحذر عندما يحتوي اسم المستخدم على نقطتين، ويعمل بالكامل من جانب العميل.
ما هي المصادقة الأساسية لـ HTTP؟
مصادقة HTTP الأساسية هي أبسط نظام بيانات اعتماد يحدده الويب. تم تحديده في RFC 7617، والذي يقع أعلى إطار عمل مصادقة HTTP العام في RFC 7235. الفكرة ضئيلة: لإثبات هويتك، ترسل رسالة Authorization رأس قيمته هي الكلمة Basicمسافة، ثم ترميز base64 لاسم المستخدم وكلمة المرور الخاصين بك متصلين بنقطتين واحدتين.
بشكل ملموس، إذا كان اسم المستخدم الخاص بك admin وكلمة المرور الخاصة بك هي secret، العميل يشكل السلسلة admin:secret، يشفرها على هيئة بايت UTF-8، ويشفر الأساس 64 تلك البايتات للحصول عليها YWRtaW46c2VjcmV0، ويرسل:
Authorization: Basic YWRtaW46c2VjcmV0
هذا هو المخطط بأكمله. لا توجد مصافحة، لا لا شيء، لا تجزئة. بساطته هي بالضبط سبب بقائه على قيد الحياة: من التافه التنفيذ على كلا الطرفين، وبالنسبة للأدوات الداخلية والسجلات الخاصة وخطافات الويب وعدد لا يحصى من واجهات برمجة التطبيقات، فهو لا يزال هو الإعداد الافتراضي. المشكلة، وهي كبيرة، هي أن التشفير قابل للعكس تمامًا، مما يشكل كل شيء يتعلق بكيفية استخدامه.
هل ترميز Base64 هو نفس التشفير؟
لا، وهذا هو الشيء الأكثر أهمية الذي يجب فهمه حول المصادقة الأساسية. Base64، المحدد في RFC 4648، هو ترميز النقل. والغرض منه هو تمثيل البيانات الثنائية أو النصية باستخدام مجموعة آمنة مكونة من 64 حرفًا قابلاً للطباعة حتى تظل على قيد الحياة عند إرسالها عبر الأنظمة التي تتوقع النص. إنه ليس تشفيرًا، ولا يستخدم أي مفتاح، وعكسه يستغرق خطوة واحدة. أي شخص يستطيع أن يرى YWRtaW46c2VjcmV0 يمكن فك تشفيرها مرة أخرى إلى admin:secret على الفور، وهو ما تفعله أداة فك التشفير '؛.
والنتيجة هي أن المصادقة الأساسية لا توفر أي سرية من تلقاء نفسها. يتم إرسال بيانات الاعتماد بشكل فعال بشكل واضح، فقط مرتديًا تمويهًا رفيعًا. ولهذا السبب فإن القاعدة الوحيدة غير القابلة للتفاوض في المصادقة الأساسية هي أنه يجب أن تنتقل عبر HTTPS فقط. يقوم TLS بتشفير الطلب بأكمله، بما في ذلك Authorization الرأس، لذا فإن بيانات الاعتماد الأساسية 64 محمية أثناء النقل. أرسل المصادقة الأساسية عبر HTTP العادي وقمت بنشر كلمة المرور الخاصة بك لأي شخص على مسار الشبكة.
أتناول هذه النقطة لأن خطوة base64 تخدع الناس وتجعلهم يعتقدون أن بيانات الاعتماد مشوشة بطريقة ذات معنى. ليس كذلك. تعامل مع الرمز المميز base64 بنفس العناية التي تتعامل بها مع كلمة المرور الأولية، لأنها قابلة للتحويل بشكل تافه. ال أدوات خصوصية البيانات عبر الإنترنت يغطي الدليل سبب قيام هذه الأداة بالتشفير في متصفحك بدلاً من الخادم، وهو ما يمثل الهدف الأساسي بالنسبة لبيانات الاعتماد المباشرة.
كيف يتم إنشاء رأس المصادقة الأساسي خطوة بخطوة؟
يتكون البناء من أربع خطوات صغيرة، والحصول على أي منها بشكل خاطئ قليلاً يؤدي إلى فشل بيانات الاعتماد بصمت
- انضم إلى القولون. تشكيل السلسلة
username:password. القولون هو المحدد. - تشفير كـ UTF-8. قم بتحويل هذه السلسلة إلى بايتات باستخدام UTF-8. وهذا مهم لأي حرف غير ASCII.
- Base64-تشفير البايتات. قم بتطبيق القاعدة القياسية 64 لإنتاج الرمز المميز.
- البادئة مع
Basic. قيمة الرأس النهائية هيBasicتليها الرمز المميز.
ال مولد يقوم بالأربعة ويسلمك الرأس النهائي. كما أنه ينتج النماذج التي تقوم بلصقها فعليًا في محطة طرفية أو قاعدة تعليمات برمجية: أمر تجعيد باستخدام -u العلم، أمر حليقة مع صريح -H 'Authorization: Basic ...' الرأس، ومقتطف الجلب، والرمز المميز بمفرده، ونموذج معلومات مستخدم URL https://user:pass@host. المهام المختلفة تريد أشكالًا مختلفة، وإعادة كتابة القاعدة 64 يدويًا هي بالضبط المكان الذي تتسلل إليه الأخطاء.
لماذا يهم اسم المستخدم أكثر من كلمة المرور؟
هناك عدم تناسق واحد في المخطط يؤدي إلى تعثر الأشخاص باستمرار، ويأتي مباشرة من الخطوة الأولى. يتم تقسيم بيانات الاعتماد على أولاً النقطتين. هذا يعني أن اسم المستخدم لا يمكن أن يحتوي على نقطتين، لأن الخادم سيقرأ النقطتين الأولتين في اسم المستخدم الخاص بك كحدود ويسلم الباقي إلى حقل كلمة المرور. على النقيض من ذلك، يمكن أن تحتوي كلمة المرور على أي عدد تريده من النقطتين، نظرًا لأن كل شيء بعد النقطتين الأولتين هو كلمة المرور.
ينص RFC 7617 على ذلك بشكل مباشر: يجب ألا يحتوي معرف المستخدم على نقطتين. من السهل انتهاك هذا دون ملاحظة، خاصة عندما يكون اسم المستخدم في حد ذاته شيئًا منظمًا مثل مفتاح API أو معرف على شكل بريد إلكتروني يتضمن نقطتين. يراقب المولد هذا بالضبط ويحذرك عندما يحتوي اسم المستخدم على نقطتين، لأن بيانات الاعتماد الناتجة سيتم فك تشفيرها مع الانقسام في المكان الخطأ وإنتاج 401 لا يعطيك أي فكرة عن السبب.
هذه هي القاعدة في الجدول، لأنها تستحق أن تكون لا لبس فيها.
| مجال | قد تحتوي على القولون؟ | سبب |
|---|---|---|
| اسم المستخدم | لا | النقطتين الأولتين هي المحدد |
| كلمة المرور | نعم | كل شيء بعد النقطتين الأوليين هو كلمة المرور |
لقد قمت بتصحيح هذا الفشل بالضبط في البرية، حيث أصدرت الخدمة API "؛ أسماء المستخدمين وحصصهم؛ التي تحتوي أحيانًا على نقطتين وقد نجح التكامل مع معظم العملاء وفشل بشكل غامض بالنسبة لعدد قليل. كان من الممكن حفظ تحذير الأداة & #39؛ بعد ظهر ذلك اليوم.
لماذا يهم ترميز UTF-8؟
بالنسبة لاسم مستخدم وكلمة مرور ASCII بالكامل، تكون خطوة التشفير غير مرئية؛ كل حرف هو بايت واحد وbase64 يفعل ما يريده. في اللحظة التي تحتوي فيها بيانات الاعتماد على حرف مميز أو برنامج نصي غير لاتيني أو رمز تعبيري، يصبح تشفير البايت حاسمًا. يوصي RFC 7617 بـ UTF-8 بدقة حتى يتفق العميل والخادم على البايتات الخاصة بهذه الأحرف.
سوف يفسد برنامج التشفير الساذج الذي يفترض أن حرفًا واحدًا هو بايت واحد، أو الذي يعتمد على واجهة برمجة تطبيقات المتصفح ذات السلوك القديم café أو пароль في البايتات الخاطئة، ولن يتطابق الرمز المميز base64 الذي ينتجه مع ما قام الخادم المتوافق بحسابه من نفس بيانات الاعتماد. والنتيجة هي 401 صامت آخر. يقوم هذا المولد بتشفير بيانات الاعتماد عبر UTF-8 يدويًا، لذا فإن كلمة المرور تشبه café:naïve ينتج بالضبط البايتات التي سيرسلها عميل RFC 7617، ويقوم جانب فك التشفير بعكسها بأمانة. إذا كان لديك بيانات اعتماد تعمل لصالح زميل في الفريق وليس آخر، فإن الحرف غير ASCII المشفر بشكل غير متسق هو المشتبه به الرئيسي.
كيف يمكنني فك تشفير رمز المصادقة الأساسي؟
نظرًا لأن التشفير قابل للعكس، فإن التحقق من بيانات الاعتماد يكون سهلاً مثل إنتاج واحدة. خذ الجزء بعد Basic ، قاعدة 64-فك تشفيرها، وقراءة النتيجة كـ UTF-8، وتقسيمها على النقطتين الأوليين. ال مولد #39؛s يقوم وضع فك التشفير بذلك: لصق كامل Authorization: Basic ... الخط، عارية Basic ... القيمة، أو الرمز المميز فقط، ويظهر لك اسم المستخدم وكلمة المرور التي يحملها.
وهذا مفيد حقًا، وليس مجرد فضول. عندما يتم تسليمك بيانات اعتماد عاملة ويطلب منك إعادة إنتاجها في بيئة جديدة، فإن فك التشفير يخبرك بالضبط باسم المستخدم وكلمة المرور التي يشفرها حتى تتمكن من ضبطهما بشكل صحيح. عندما يفشل التكامل، فإن فك تشفير الرمز المميز الذي ترسله بالفعل ومقارنته بما كنت تقصده غالبًا ما يكون أسرع طريقة لاكتشاف مساحة ضالة أو حقل خاطئ أو نقطتين في المكان الخطأ. وهو تذكير حي بنقطة السرية أعلاه: إذا كان بإمكانك فك تشفيرها بهذه السهولة، فيمكن لأي شخص يعترضها عبر HTTP عادي.
حيث يتناسب المولد مع الأدوات الأخرى
يعد المصادقة الأساسية واحدة من العديد من أدوات الاعتماد والطلب الموجودة على الموقع والتي تشترك في نفس النموذج من جانب العميل، بدون تحميل. عندما يكون الرمز المميز الذي تقوم بفحصه هو رمز مميز لحامله وليس المصادقة الأساسية، فإن فك JWT يقرأ المطالبات من رمز ويب JSON. عندما تحتاج إلى تجزئة بدلاً من ترميز، للحصول على المجموع الاختباري أو ملخص كلمة المرور، فإن مولد التجزئة يحسبها. عندما تريد فقط تشفير أو فك تشفير الأساس 64 التعسفي بدلاً من بيانات الاعتماد على وجه التحديد، فإن محول base64 يعالج الحالة العامة. وعندما تقوم بتصحيح الطلب نفسه وتريد معرفة العميل الذي أرسله، فإن محلل وكيل المستخدم يقرأ رأس وكيل المستخدم.
للحصول على خريطة أوسع لكيفية عمل أدوات الطلب والاستجابة هذه معًا، فإن مجموعة أدوات مطور الويب يمشي Roundup خلال جلسة تصحيح أخطاء واقعية، و أدوات إنتاجية المطور أغلفة الدليل تجمع مجموعة شخصية منهم. نادرًا ما يأتي المصادقة الأساسية بمعزل عن غيرها؛ عادةً ما يكون سطرًا واحدًا في الطلب الذي تحاول تنفيذه.
مثال عملي: توصيل تكامل API
اسمحوا لي أن أضع هذا في المهمة التي قمت بها أكثر. أنت تقوم بدمج خدمة خارجية تقول مستنداتها بالمصادقة باستخدام المصادقة الأساسية باستخدام مفتاح API كاسم مستخدم وكلمة مرور فارغة، أو مفتاح وزوج سري. تمنحك المستندات بيانات الاعتماد ولكن ليس الرأس، ويفشل الطلب الأول.
المسار الموثوق به هو إنشاء الرأس بشكل صريح واختباره باستخدام التجعيد قبل كتابة سطر من كود التطبيق. لصق المفتاح والسري في مولد، انسخ curl -H النموذج وتشغيله مقابل نقطة نهاية معروفة. إذا نجح التجعيد ولم ينجح الكود الخاص بك، فستكون المشكلة في التعليمات البرمجية '؛ التي تطلب الإنشاء، وليس بيانات الاعتماد، وقمت للتو بقطع مساحة البحث إلى النصف. إذا فشل التجعيد أيضًا، فإن بيانات الاعتماد نفسها خاطئة، ويؤكد فك تشفير الرمز المميز الحقل الموجود خارجًا بالضبط.
في البرنامج المساعد WordPress، غالبًا ما أحتاج إلى استدعاء واجهة برمجة تطبيقات خارجية من PHP، وقيمة الرأس الصحيحة هي ما أقوم بتغذيته wp_remote_get عبر ال Authorization حجة الرأس. في Laravel يذهب إلى withHeaders اتصل بعميل HTTP، أو أستخدم إطار العمل '؛s withBasicAuth المساعد، الذي يبني نفس الرأس بالنسبة لي. وفي كلتا الحالتين، فإن الحصول على قيمة الرأس المعروفة من المولد يعني أنني أقوم بتصحيح رمز الطلب الخاص بي مقابل بيانات الاعتماد التي أثبت نجاحها بالفعل، بدلاً من تصحيح كليهما في وقت واحد. حالة كلمة المرور الفارغة هي المكان الذي يحصل فيه المولد على الاحتفاظ به، لأنه من السهل نسيان ذلك key: مع النقطتين الخلفيتين، تكون بيانات الاعتماد مختلفة، وغالبًا ما تكون صحيحة، من key وحيد.
الانضباط الأخير هو الأمان. لا تقم بلصق الرأس الناتج في مستند مشترك أو تذكرة أو دردشة، ولا ترسل مصادقة أساسية على أي شيء سوى HTTPS. الرمز المميز هو كلمة المرور. نظرًا لأن هذه الأداة تقوم بالتشفير في متصفحك ولا تقوم بتحميل أي شيء أبدًا، فإن إنشاء بيانات الاعتماد أمر آمن؛ حيث يذهب بعد ذلك عليك.
متى يجب أن أستخدم المصادقة الأساسية، ومتى لا ينبغي لي ذلك؟
المصادقة الأساسية ليست الأداة المناسبة لكل مهمة، ومعرفة المكان المناسب يبقيك بعيدًا عن المشاكل. قوتها هي البساطة: بالنسبة للمكالمات من خادم إلى خادم، والأدوات الداخلية، وسجلات الحزم الخاصة، ووظائف CI، وخطافات الويب حيث يثق الطرفان ببعضهما البعض بالفعل ويتم تشغيل كل شيء عبر HTTPS، فمن الصعب التغلب عليها. لا يوجد شيء للتفاوض عليه، ولا يوجد رمز للتحديث، وكل عميل ومكتبة HTTP يدعمانه خارج الصندوق. عندما تتحكم في كلا الجانبين ويتم تشفير الاتصال، فإن المصادقة الأساسية هي خيار معقول تمامًا واستمر في العمل لمدة ثلاثين عامًا.
تظهر نقاط ضعفه لحظة خروجك من هذا المربع. نظرًا لأنه يتم إرسال بيانات الاعتماد عند كل طلب، فإن سطر سجل واحد مسرب أو وكيل يسجل الرؤوس يكشفها بشكل دائم، وتدويرها يعني تغييرها في كل مكان مرة واحدة. ليس لديها مفهوم النطاق، لذا فإن بيانات الاعتماد الأساسية هي كل شيء أو لا شيء: لا يمكنها منح حق الوصول للقراءة فقط أو تنتهي صلاحيتها بعد ساعة. ويضع كلمة مرور حقيقية طويلة الأمد على السلك في كل مكالمة، في حين تتيح لك المخططات القائمة على الرمز المميز توزيع بيانات اعتماد قصيرة العمر وضيقة النطاق بدلاً من ذلك.
بالنسبة للمصادقة التي تواجه المستخدم، أو في أي مكان تحتاج فيه إلى نطاقات أو انتهاء صلاحية أو إلغاء، فإن الرمز المميز لحامله هو النموذج الأفضل، و فك JWT هي الأداة المصاحبة لفحص تلك. قاعدة أساسية مفيدة: الوصول إلى المصادقة الأساسية لمكالمات آلة إلى آلة، يمكنك التحكم فيها بشكل كامل، والوصول إلى الرموز المميزة عندما يتعلق الأمر بطرف ثالث، أو جلسة متصفح، أو حدود الأذونات. يلخص الجدول أدناه التجارة.
| استخدم المصادقة الأساسية لـ | تفضل الرموز ل |
|---|---|
| تستدعي واجهة برمجة التطبيقات من خادم إلى خادم التحكم | جلسات تواجه المستخدم |
| الأدوات الداخلية والسجلات الخاصة | الوصول إلى النطاق أو القراءة فقط |
| وظائف CI وخطافات الويب عبر HTTPS | أوراق الاعتماد التي يجب أن تنتهي صلاحيتها |
الأسئلة الشائعة
ما هي المصادقة الأساسية لـ HTTP؟ مصادقة HTTP الأساسية هي نظام يرسل فيه العميل اسم مستخدم وكلمة مرور مع كل طلب في رأس التفويض. القيمة هي الكلمة Basic متبوعة بتشفير base64 لاسم المستخدم: كلمة المرور. تم تعريفه في RFC 7617 وهو أبسط طريقة للخادم للتحقق من بيانات الاعتماد.
كيف يتم إنشاء رأس المصادقة الأساسي؟ انضم إلى اسم المستخدم وكلمة المرور بنقطتين واحدتين لتكوين اسم المستخدم: كلمة المرور، وقم بتشفير تلك السلسلة كـ UTF-8 بايت، وقم بتشفير البايتات الأساسية 64، وقم بوضع بادئة النتيجة بـ Basic. الرأس النهائي هو التفويض: أساسي متبوعًا بهذا الرمز المميز.
هل المصادقة الأساسية آمنة؟ فقط عبر HTTPS. Base64 هو التشفير، وليس التشفير، لذلك يمكن لأي شخص يمكنه قراءة الرأس فك تشفير كلمة المرور على الفور. لا يوفر المصادقة الأساسية أي سرية في حد ذاته ويجب دائمًا إرسالها عبر اتصال TLS لتكون آمنة.
هل يمكن أن يحتوي اسم المستخدم على نقطتين؟ لا. تفصل النقطتين الأولتين اسم المستخدم عن كلمة المرور، لذلك سيتم قراءة النقطتين الموجودتين في اسم المستخدم بشكل خاطئ كحدود وتقسيم بيانات الاعتماد في المكان الخطأ. قد تحتوي كلمة المرور على أي عدد من النقطتين. يحذرك المولد إذا كان اسم المستخدم يحتوي على واحد.
كيف يمكنني فك تشفير رمز المصادقة الأساسي؟ خذ الجزء الأساسي 64 بعد Basic، وقم بفك تشفيره، واقرأه كنص UTF-8. والنتيجة هي اسم المستخدم: كلمة المرور، مقسمة على النقطتين الأوليين. الصق أي رأس مصادقة أساسي في وضع فك تشفير الأداة '؛s للقيام بذلك على الفور.
ما هو المعادل الضفيرة؟ الضفيرة - اسم المستخدم: كلمة المرور https://example.com يفعل الشيء نفسه، لأن curl يبني التفويض: الرأس الأساسي لك من قيمة -u. تعرض الأداة كلاً من هذا النموذج ونموذج رأس -H الصريح حتى تتمكن من نسخ أيهما يناسب.
هل ترسل هذه الأداة بيانات الاعتماد الخاصة بي إلى أي مكان؟ لا. يتم تشغيل التشفير وفك التشفير بالكامل في متصفحك باستخدام JavaScript. لا يتم تحميل اسم المستخدم وكلمة المرور الخاصة بك مطلقًا إلى أي خادم، لذلك من الآمن استخدامها مع بيانات الاعتماد الحقيقية والحية.
لماذا تستخدم ترميز UTF-8 لبيانات الاعتماد؟ يوصي RFC 7617 بـ UTF-8 بحيث يتم تشفير أسماء المستخدمين وكلمات المرور غير ASCII بشكل متسق بين العميل والخادم. برنامج تشفير يفترض أن ASCII قد يفسد الحروف المحركة أو البرامج النصية غير اللاتينية، مما ينتج عنه رمز مميز لا يمكن للخادم مطابقته.
