استيراد المستخدمين دون إعادة تعيين كلمة المرور

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

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

دوال تجزئة كلمات المرور أكثر قابلية للنقل مما يظن الناس

دالة تجزئة كلمة المرور ليست خوارزمية سرّية. bcrypt هو bcrypt. تحمل دالة تجزئة bcrypt عامل التكلفة الخاص بها والـ salt داخل السلسلة نفسها، لذا فإن أي شيء يطبّق bcrypt يمكنه التحقق من دالة تجزئة أنتجها أي نظام bcrypt آخر. وينطبق الأمر نفسه على صيغة PBKDF2 التي يستخدمها ASP.NET Identity: موثّقة، ومُصدَّرة بإصدارات، وذاتية الوصف. وإذا كنت تعرف ما الذي بين يديك، يمكنك التحقق من كلمة مرور مقابلها دون أن تعرف كلمة المرور إطلاقاً.

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

جزء المسار المزدوج

التعقيد يكمن في أن المصادر المختلفة تسلّمك صيغاً مختلفة، وأي أداة استيراد جيدة تتحقق من كليهما:

• من Duende / ASP.NET Identity المستضافة ذاتياً: تتحقق دوال تجزئة V3 PBKDF2 (وأي bcrypt قديم) أصلياً ويُعاد تجزئتها عند أول تسجيل دخول. هذه هي الحالة السهلة، لأنها المخطط نفسه الذي تستخدمه الوجهة بالفعل. وتُفاجأ معظم الفرق بأنها بهذه النظافة.
• من Auth0: تتحقق دوال تجزئة bcrypt حرفياً. والمشكلة ليست في الصيغة، بل في الحصول عليها.

متى يتعذّر ذلك فعلاً

لا تُرجع Management API الخاصة بـ Auth0 أبداً دوال تجزئة كلمات المرور. هذه سياسة متعمّدة، وليست ثغرة في أدوات أي أحد، ويجدر بك أن تشكّ في أي "تصدير Auth0 بنقرة واحدة" يدّعي تضمين كلمات المرور دونها. المسار المدعوم هو تصدير مُجمَّع بمساعدة الدعم: ملف NDJSON يحتوي على دالة تجزئة bcrypt لكل مستخدم. احصل على ذلك الملف وتُستورَد دوال التجزئة حرفياً، مع الترحيل الكسول وكل ما يتبعه، ويصبح الانتقال غير محسوس.

وإن لم تستطع انتظاره، فالبديل هو النسخة الصادقة من الفقرة الاعتذارية: يضبط المستخدمون كلمة مرور جديدة عند أول تسجيل دخول. لم يُفقد شيء، لأنه لم تكن هناك دالة تجزئة لنقلها. والفارق أنك اخترت ذلك عن وعي، لا لأن الأداة عجزت عن تقديم ما هو أفضل.

لماذا يهمّ هذا أكثر مما يبدو

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

لذا قبل أن تقبل عبارة "الجميع يعيد التعيين"، اطرح السؤالين. في معظم عمليات الانتقال تكون الإجابة نعم على كليهما، ولم تكن الفقرة الاعتذارية ضرورية قط.

انظر ما الذي ستنقله عملية الاستيراد ، المعاينة للقراءة فقط وتُظهر لك كل شيء قبل كتابة أي شيء.