لا تستخدم مفاتيح المرور لتشفير بيانات المستخدم

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

المصادقة والتشفير وظيفتان مختلفتان بشكل أساسي

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

عندما تقوم بالمصادقة باستخدام مفتاح مرور، يقوم جهازك بإنشاء توقيع مشفر يثبت أنك تمتلك المفتاح الخاص المرتبط بحسابك. يتحقق الخادم من هذا التوقيع ويمنح حق الوصول. لا يتمكن الخادم - أو حتى تطبيقك - في أي وقت من الأوقات من الوصول إلى مادة المفتاح الخاص نفسه. هذه ميزة وليست قيدًا. يعتمد نموذج الأمان الكامل لمفاتيح المرور على المفتاح الخاص الذي لا يترك المنطقة الآمنة لجهازك مطلقًا. لكن التشفير يتطلب استخدام مفتاح لتحويل البيانات، واستخدام نفس المفتاح لاحقًا (أو نظيره) لعكس التحويل. إذا لم تتمكن من الوصول إلى المفتاح بشكل موثوق، فلن تتمكن من فك التشفير بشكل موثوق.

تحتاج الأنظمة الأساسية مثل Mewayz التي تدير معلومات الأعمال الحساسة - الفواتير، وسجلات الرواتب، وجهات اتصال CRM، ومستندات الموارد البشرية عبر 207 وحدة - إلى استراتيجيات تشفير مبنية على مفاتيح متينة وقابلة للاسترداد ويمكن الوصول إليها باستمرار. إن بناء ذلك على أساس مصمم خصيصًا لمنع الوصول إلى المفتاح يعد تناقضًا معماريًا.

لماذا تقاوم مفاتيح المرور استخدامها كمفاتيح تشفير؟

تم تصميم مواصفات WebAuthn، التي تدعم مفاتيح المرور، بشكل متعمد مع قيود تجعل استخدام التشفير غير عملي. يكشف فهم هذه القيود عن سبب عدم كون هذه فجوة يمكن للهندسة الذكية أن تسدها، بل هي حدود تصميم أساسية.

لا يوجد تصدير للمفاتيح: يتم تخزين المفاتيح الخاصة التي تم إنشاؤها أثناء تسجيل مفتاح المرور في جيوب آمنة مدعومة بالأجهزة (TPM أو Secure Enclave أو ما يعادلها). لا يوفر نظام التشغيل وواجهات برمجة تطبيقات المتصفح أي آلية لاستخراج المواد الأساسية الأولية. يمكنك أن تطلب من المفتاح التوقيع على شيء ما، لكن لا يمكنك قراءة المفتاح نفسه.

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

التوفر المرتبط بالجهاز: حتى في حالة مزامنة مفاتيح المرور (iCloud Keychain، Google Password Manager)، يعتمد التوفر على مشاركة النظام البيئي. قد يفقد المستخدم الذي يقوم بالتسجيل على iPhone ثم يتحول لاحقًا إلى Android إمكانية الوصول. يواجه المستخدم الذي فقد جهازه أو سُرق أو تمت إعادة ضبطه على إعدادات المصنع نفس المشكلة.

الاستجابة للتحدي فقط: تعرض WebAuthn API navigator.credentials.get() الذي يُرجع تأكيدًا موقعًا، وليس مادة رئيسية أولية. تتلقى توقيعًا عبر اختبار يقدمه الخادم - وهو مفيد لإثبات الهوية، وغير مفيد لاشتقاق مفتاح التشفير.

لا توجد مرونة في الخوارزمية: تستخدم مفاتيح المرور عادةً ECDSA مع منحنى P-256. حتى لو كان بإمكانك الوصول إلى المفتاح، فإن ECDSA عبارة عن خوارزمية توقيع

Frequently Asked Questions

Why can't passkeys be used to encrypt user data?

Passkeys are designed exclusively for authentication, not encryption. They rely on public-key cryptography to verify your identity during login, but the private key never leaves your device and isn't accessible to applications. Encryption requires stable, reproducible keys that can consistently decrypt data over time. Passkeys lack this capability by design, making them fundamentally unsuitable for protecting stored user information.

What happens if you try to encrypt data with passkeys anyway?

You risk building a brittle system where users get permanently locked out of their own data. Passkeys can be revoked, rotated, or replaced across devices without warning. If encrypted data is tied to a specific passkey that gets deleted or updated, there is no recovery path. This creates a catastrophic data-loss scenario that no amount of engineering workaround can reliably prevent.

What should developers use instead of passkeys for data encryption?

Developers should use purpose-built encryption solutions such as AES-256 with proper key management, envelope encryption, or established libraries like libsodium. Keep authentication and encryption as separate concerns. Use passkeys for what they excel at — passwordless login — and dedicated encryption keys managed through secure key derivation and storage systems for protecting sensitive user data.

How does Mewayz handle authentication and data security for businesses?

Mewayz provides a 207-module business OS starting at $19/mo that separates authentication from data protection using industry best practices. Rather than misusing passkeys, the platform at app.mewayz.com implements proper encryption layers alongside secure login flows, ensuring businesses can protect customer data reliably without risking the lockout scenarios that come from conflating authentication with encryption.

Related Posts

• أداة العزل في سطر الأوامر في macOS غير المعروفة (2025)
• لماذا أشعر بالقلق بشأن فقدان الوظيفة والأفكار حول الميزة النسبية
• تطبيق طقس للطرفية مع رسوم ASCII متحركة مدعومة ببيانات الطقس الفورية
• Raspberry Pi Pico 2 بتردد 873.5 ميجاهرتز مع إساءة استخدام جهد النواة 3.05 فولت