مولّدات كلمات المرور ولماذا يغيّر Rust قواعد اللعبة

الإنتروبيا، CSPRNG، عبارات مرور Diceware وأمان الذاكرة: لماذا لغة خزنتك مهمة بقدر جودة المولّد.

المولّد الصحيح، الصحيحة . ليست كل مولّدات كلمات المرور متساوية — واللغة التي تُكتب بها خزنتك ليست تفصيلاً هندسياً ثانوياً. تفكيك للإنتروبيا، وأنماط التوليد، ولماذا يفرض Rust نفسه تحت الغطاء. عندما يقول مدير كلمات المرور إنه «يولّد كلمة مرور قوية»، يظهر سؤالان: هل هي غير قابلة للتنبؤ فعلاً ، أي جودة العشوائية، و ماذا يحدث لها في الذاكرة بعد عرضها؟ الأول يتعلق بأنماط التوليد. والثاني باللغة التي تشغّل التطبيق. هذا المقال يغطي الاثنين. ~100 bits كلمة مرور عشوائية من 16 حرفاً (قوية جداً) ~77 bits عبارة مرور Diceware من 6 كلمات (EFF) 12,9 bits إنتروبيا يضيفها كل لفظ Diceware (قائمة من 7 776 كلمة) الإنتروبيا: المقياس الوحيد الذي يهم لا تُقاس قوة كلمة المرور بما نشعر أنه «تعقيد»، بل بـ الإنتروبيا : عدد بتات عدم اليقين لدى المهاجم. كلما زاد عدد التركيبات الممكنة، انفجر كلفة هجوم القوة الغاشمة. كلمة مرور من 16 حرفاً مأخوذة من كامل أبجدية ASCII تصل إلى نحو 100 bits — أي ضمن نطاق «قوية جداً». نقطة حاسمة تُنسى كثيراً: لا قيمة للإنتروبيا إلا إذا كان مصدر العشوائية هو CSPRNG ، أي مولّد أرقام شبه عشوائية آمن تشفيرياً. إن Math.random() التقليدي قابل للتنبؤ ويفسد كل ما بعده. التطبيقات الجيدة تقرأ الإنتروبيا من نظام التشغيل: /dev/urandom أو getrandom(2) على Unix، و CNG على Windows. أربع عائلات من المولّدات مدير كلمات المرور الجيد لا يقدّم «مولّداً واحداً»، بل عدة أنماط تناسب الاستخدام. القاعدة هي: سهولة التذكّر تُدفع بطول أكبر . إليك العائلات الأربع، من الأعلى كثافة إلى الأقرب للبشر. المنعكس الصحيح: تكييف الإنتروبيا مع الاستخدام لحساب ويب محمي بصفحة تسجيل دخول تحدّ من المعدّل، يكون المهاجم مقيّداً ببضع مئات من المحاولات في الثانية: حتى 50 bits تصمد لأزمنة جيولوجية. الإنتروبيا الزائدة لا تكون منطقية إلا للأسرار غير المتصلة بالإنترنت، مثل مفتاح التشفير أو seed لمحفظة crypto، حيث يمكن تنفيذ الهجوم بتوازٍ هائل. لهذه الأسرار عالية القيمة جداً، يبقى رمي نرد مادي حقيقي، أي Diceware بالمعنى الحرفي، الخيار الأقصى: فهو يزيل أي اعتماد على جودة CSPRNG أو على متصفح مخترق. لماذا يغيّر Rust المعادلة توليد كلمة مرور جيدة هو نصف العمل. النصف الآخر هو: ألا تتركها عالقة في الذاكرة . بعد عرضها أو فك تشفيرها، تعيش كلمة مرورك في الذاكرة الحية — وهنا تصبح لغة التطبيق عاملاً حاسماً. أفادت Microsoft بأن 70 % من الثغرات الأمنية التي تواجهها هي أخطاء ذاكرة، مثل buffer overflow وuse-after-free وغيرها. ولاحظت Google النسبة نفسها على Chrome وAndroid. هذه بالضبط فئات العيوب التي يزيلها Rust أثناء الترجمة ، عبر نموذج الملكية ( ownership ) والاستعارة ( borrowing )، من دون جامع قمامة. أرقام Google واضحة: انخفضت ثغرات ذاكرة Android من 223 في 2019 إلى أقل من 50 في 2024 ، ونزلت تحت عتبة 20 % من الإجمالي لأول مرة. ويعرض كود Rust الجديد كثافة ثغرات ذاكرة أقل بما يصل إلى 1000× من كود C/C++ التاريخي، ومع ذلك 4× rollbacks أقل و25 % وقت مراجعة أقل. 1. أمان ذاكرة بلا جامع قمامة. لغات مثل Java أو Python آمنة ذاكرةً، لكن garbage collector يحرر الذاكرة بطريقة غير حتمية: قد يبقى السر فيها إلى أجل غير معلوم، مكشوفاً أمام memory dump أو هجوم cold-boot. يحرر Rust الذاكرة بطريقة حتمية بمجرد أن لا تعود البيانات مستخدمة. 2. مسح صريح باستخدام zeroize . لا يضمن Rust أن الذاكرة المحررة تُكتب فوقها أصفار. تسد crate zeroize هذه الفجوة: عند تغليف السر في Zeroizing ، نضمن الكتابة فوقه بالأصفار — عبر كتابة volatile لا يستطيع المترجم تحسينها بعيداً — في اللحظة الدقيقة التي يخرج فيها من النطاق. 3. نظام أنواع يفرض الاستخدام الصحيح للتشفير. يتيح نظام الأنواع الصارم في Rust حصر طريقة استخدام البيانات الحساسة وعدد مرات استخدامها. يمكن مثلاً نمذجة مفتاح لا يمكن استخدامه إلا مرة واحدة، ويرفض المترجم أي إعادة استخدام. صدق تقني: Rust ليس عصا سحرية يبقى كود unsafe والاعتماديات الخارجية أسطح هجوم — وقد أصلحت Google بالفعل ثغرة (CVE-2025-48530) في كتلة unsafe ضمن محلل Rust قبل أي طرح في الإنتاج. أمان الذاكرة هو طبقة ، وليس غاية بحد ذاته: فهو يتكامل مع دفاع معمق مثل KDF قوي كـ Argon2id، وبنية zero-knowledge، والقفل التلقائي، وMFA. ما يجب أن تطلبه من مدير كلمات المرور عند اختيار — أو تقييم — مدير كلمات مرور، اطرح أربعة أسئلة عملية: 1. هل يعتمد المولّد على CSPRNG النظام ، وهل يعرض الإنتروبيا بالـ bits؟ 2. هل يقدّم وضع passphrase Diceware/EFF لكلمة المرور الرئيسية؟ 3. هل يتم التوليد محلياً (client-side) ، من دون المرور عبر خادم؟ 4. هل القلب الحساس مكتوب بلغة آمنة ذاكرةً مع مسح صريح للأسرار؟ توليد آمن. خزنة مصممة لتدوم. كلمات مرور عالية الإنتروبيا، عبارات مرور قابلة للحفظ، وقلب مصمم لأمان الذاكرة. محتوى معلوماتي لأغراض تعليمية. الإحصاءات المذكورة (Google/Android، Microsoft، Diceware/EFF) مأخوذة من المصادر المدرجة أعلاه. أمثلة كود Rust توضيحية ومبسطة.

La génération de mots de passe est une affaire d'entropie, pas de hasard Diceware / EFF : ~77 bits sur 6 mots et arbitrage mémorabilité vs longueur Méthode Diceware : 7 776 mots, 12,9 bits par mot Générateur Diceware s'appuyant sur le CSPRNG du navigateur Développement sûr avec le modèle mémoire de Rust (retour de 1Password)Failles mémoire Android : de 76 % à 24 % grâce à Rust Bugs mémoire Android sous 20 % ; densité 1000× inférieure ; CVE-2025-48530 Crate zeroize : effacement sécurisé de la mémoire Zeroize : pourquoi Rust ne suffit pas seul pour effacer un secret Concevoir un coffre chiffré en Rust, vu par un pentester

العودة إلى المدونة

أمان تقني · قراءة 7 دقائق

المولّد الصحيح،
اللغة الصحيحة.

ليست كل مولّدات كلمات المرور متساوية — واللغة التي تُكتب بها خزنتك ليست تفصيلاً هندسياً ثانوياً. تفكيك للإنتروبيا، وأنماط التوليد، ولماذا يفرض Rust نفسه تحت الغطاء.

نُشر في يونيو 2026 · مدة القراءة 7 دقائق

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

~100 bits

كلمة مرور عشوائية من 16 حرفاً (قوية جداً)

~77 bits

عبارة مرور Diceware من 6 كلمات (EFF)

12,9 bits

إنتروبيا يضيفها كل لفظ Diceware (قائمة من 7 776 كلمة)

01 / الأساسياتالإنتروبيا: المقياس الوحيد الذي يهم

لا تُقاس قوة كلمة المرور بما نشعر أنه «تعقيد»، بل بـالإنتروبيا: عدد بتات عدم اليقين لدى المهاجم. كلما زاد عدد التركيبات الممكنة، انفجر كلفة هجوم القوة الغاشمة. كلمة مرور من 16 حرفاً مأخوذة من كامل أبجدية ASCII تصل إلى نحو 100 bits — أي ضمن نطاق «قوية جداً».

نقطة حاسمة تُنسى كثيراً: لا قيمة للإنتروبيا إلا إذا كان مصدر العشوائية هو CSPRNG، أي مولّد أرقام شبه عشوائية آمن تشفيرياً. إن Math.random() التقليدي قابل للتنبؤ ويفسد كل ما بعده. التطبيقات الجيدة تقرأ الإنتروبيا من نظام التشغيل: /dev/urandom أو getrandom(2) على Unix، وCNG على Windows.

02 / الأنماطأربع عائلات من المولّدات

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

عشوائي خالص

j7$kQ!mP2#xR9vL@

~100 bits على 16 حرفاً

أعلى كثافة لكل حرف. مثالي للحسابات المخزنة في الخزنة، والتي لا تحتاج أبداً إلى كتابتها من الذاكرة. ينبغي اعتماده افتراضياً.

عبارة مرور (Diceware / EFF)

Granite-Bicycle-Phantom-Violet-9

~77 bits على 6 كلمات

كلمات تُسحب عشوائياً من قائمة تضم 7 776 كلمة. أطول على الشاشة لكنها قابلة للحفظ خلال ثوانٍ — وهي الخيار المثالي لـكلمة المرور الرئيسية، التي لا تريد كتابتها في أي مكان.

قابل للحفظ / قابل للنطق

Crimson7!Falcon$Reef

إنتروبيا متوسطة

نمط «كلمة-رقم-رمز» أسهل قراءة بصوت عالٍ أو كتابة على الهاتف. حل وسط مقبول، لكن عند الطول نفسه تكون الإنتروبيا أضعف: إذا كانت سهولة الحفظ هي الهدف، فعبارة المرور تبقى أفضل.

PIN رقمي

8392 4471

منخفضة — استخدام محدد

مخصص للحالات التي لا يُقبل فيها إلا الأرقام. ينبغي تجنبه خارج السياقات المقيدة.

المنعكس الصحيح: تكييف الإنتروبيا مع الاستخدام

لحساب ويب محمي بصفحة تسجيل دخول تحدّ من المعدّل، يكون المهاجم مقيّداً ببضع مئات من المحاولات في الثانية: حتى 50 bits تصمد لأزمنة جيولوجية. الإنتروبيا الزائدة لا تكون منطقية إلا للأسرار غير المتصلة بالإنترنت، مثل مفتاح التشفير أو seed لمحفظة crypto، حيث يمكن تنفيذ الهجوم بتوازٍ هائل. لهذه الأسرار عالية القيمة جداً، يبقى رمي نرد مادي حقيقي، أي Diceware بالمعنى الحرفي، الخيار الأقصى: فهو يزيل أي اعتماد على جودة CSPRNG أو على متصفح مخترق.

03 / تحت الغطاءلماذا يغيّر Rust المعادلة

توليد كلمة مرور جيدة هو نصف العمل. النصف الآخر هو: ألا تتركها عالقة في الذاكرة. بعد عرضها أو فك تشفيرها، تعيش كلمة مرورك في الذاكرة الحية — وهنا تصبح لغة التطبيق عاملاً حاسماً.

أفادت Microsoft بأن 70 % من الثغرات الأمنية التي تواجهها هي أخطاء ذاكرة، مثل buffer overflow وuse-after-free وغيرها. ولاحظت Google النسبة نفسها على Chrome وAndroid. هذه بالضبط فئات العيوب التي يزيلها Rust أثناء الترجمة، عبر نموذج الملكية (ownership) والاستعارة (borrowing)، من دون جامع قمامة.

أرقام Google واضحة: انخفضت ثغرات ذاكرة Android من 223 في 2019 إلى أقل من 50 في 2024، ونزلت تحت عتبة 20 % من الإجمالي لأول مرة. ويعرض كود Rust الجديد كثافة ثغرات ذاكرة أقل بما يصل إلى 1000× من كود C/C++ التاريخي، ومع ذلك 4× rollbacks أقل و25 % وقت مراجعة أقل.

1. أمان ذاكرة بلا جامع قمامة. لغات مثل Java أو Python آمنة ذاكرةً، لكن garbage collector يحرر الذاكرة بطريقة غير حتمية: قد يبقى السر فيها إلى أجل غير معلوم، مكشوفاً أمام memory dump أو هجوم cold-boot. يحرر Rust الذاكرة بطريقة حتمية بمجرد أن لا تعود البيانات مستخدمة.

2. مسح صريح باستخدام zeroize. لا يضمن Rust أن الذاكرة المحررة تُكتب فوقها أصفار. تسد crate zeroize هذه الفجوة: عند تغليف السر في Zeroizing، نضمن الكتابة فوقه بالأصفار — عبر كتابة volatile لا يستطيع المترجم تحسينها بعيداً — في اللحظة الدقيقة التي يخرج فيها من النطاق.

3. نظام أنواع يفرض الاستخدام الصحيح للتشفير. يتيح نظام الأنواع الصارم في Rust حصر طريقة استخدام البيانات الحساسة وعدد مرات استخدامها. يمكن مثلاً نمذجة مفتاح لا يمكن استخدامه إلا مرة واحدة، ويرفض المترجم أي إعادة استخدام.

مسح تلقائي في الذاكرةuse zeroize::Zeroizing;

fn unlock_vault(master: &str) {
    let dek = Zeroizing::new(derive_key(master));
    // ... déchiffrement du coffre ...
}   // `dek` est écrasé par des zéros ici, automatiquement

ثغرات الذاكرة — ANDROID (% من الإجمالي)

76%

2019

24%

2024

تبني RUST

لدى Google، أدى تبني Rust إلى خفض حصة ثغرات الذاكرة في Android من 76 % (2019) إلى 24 % (2024)، أي أقل بكثير من معيار القطاع (~70 %).

صدق تقني: Rust ليس عصا سحرية

يبقى كود unsafe والاعتماديات الخارجية أسطح هجوم — وقد أصلحت Google بالفعل ثغرة (CVE-2025-48530) في كتلة unsafe ضمن محلل Rust قبل أي طرح في الإنتاج. أمان الذاكرة هو طبقة، وليس غاية بحد ذاته: فهو يتكامل مع دفاع معمق مثل KDF قوي كـ Argon2id، وبنية zero-knowledge، والقفل التلقائي، وMFA.