it-swarm.asia

لماذا يفضل char [] على String لكلمات المرور؟

في Swing ، يحتوي حقل كلمة المرور على طريقة getPassword() (بإرجاع char[]) بدلاً من الأسلوب getText() المعتاد (بإرجاع String). وبالمثل ، صادفت اقتراحًا بعدم استخدام String للتعامل مع كلمات المرور.

لماذا يشكل String تهديدًا للأمان عندما يتعلق الأمر بكلمات المرور؟ من غير المريح استخدام char[].

3159
Ahamed

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

باستخدام صفيف ، يمكنك مسح البيانات بوضوح بعد الانتهاء منها. يمكنك الكتابة فوق الصفيف بأي شيء تريده ، ولن تكون كلمة المرور موجودة في أي مكان في النظام ، حتى قبل تجميع البيانات المهملة.

إذن ، نعم ، هذا (هو) يمثل مشكلة أمنية - ولكن حتى استخدام char[] يقلل فقط من فرصة المهاجم ، وهذا فقط لهذا النوع من الهجوم.

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

4017
Jon Skeet

في حين أن الاقتراحات الأخرى هنا تبدو صالحة ، هناك سبب وجيه آخر. من خلال String العادي ، يكون لديك فرص أكبر بكثير من بطريق الخطأ طباعة كلمة المرور لتسجيلات أو شاشات أو مكان آخر غير آمن. char[] أقل عرضة للخطر.

النظر في هذا:

public static void main(String[] args) {
    Object pw = "Password";
    System.out.println("String: " + pw);

    pw = "Password".toCharArray();
    System.out.println("Array: " + pw);
}

مطبوعات:

String: Password
Array: [[email protected]
1152
Konrad Garus

لاقتباس وثيقة رسمية ، يشير دليل Java Cryptography Architecture إلى هذا عن char[] مقابل String كلمات المرور (حول التشفير القائم على كلمة المرور ، ولكن هذا بشكل عام أكثر حول كلمات المرور بالطبع):

يبدو من المنطقي جمع كلمة المرور وتخزينها في كائن من النوع Java.lang.String. ومع ذلك ، إليك التحذير: Objects من النوع String غير قابلة للتغيير ، أي ، لا توجد طرق محددة تسمح لك بتغيير (الكتابة الفوقية) أو التخلص من محتويات String بعد الاستخدام. تجعل هذه الميزة String_ الكائنات غير مناسبة لتخزين المعلومات الحساسة للأمان مثل كلمات مرور المستخدم. يجب عليك دائمًا تجميع وتخزين المعلومات الحساسة للأمان في مجموعة char بدلاً من ذلك.

المبدأ التوجيهي 2-2 من إرشادات الترميز الآمن للغة برمجة Java ، الإصدار 4.0 يقول أيضًا شيئًا مشابهًا (على الرغم من أنه في الأصل في سياق التسجيل):

المبدأ التوجيهي 2-2: لا تقم بتسجيل معلومات شديدة الحساسية

بعض المعلومات ، مثل أرقام الضمان الاجتماعي (SSN) وكلمات المرور ، حساسة للغاية. لا ينبغي الاحتفاظ بهذه المعلومات لفترة أطول من اللازم ولا حيث يمكن رؤيتها ، حتى من قِبل المسؤولين. على سبيل المثال ، لا ينبغي إرسالها إلى ملفات السجل ولا يجب اكتشاف وجودها من خلال عمليات البحث. يمكن الاحتفاظ ببعض البيانات المؤقتة في بنيات بيانات قابلة للتغيير ، مثل صفائف char ، ومسحها فور الاستخدام. قلل بنيات البيانات من الفعالية في أنظمة وقت تشغيل Java النموذجية حيث يتم نقل الكائنات في الذاكرة بشفافية إلى المبرمج.

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

650
Bruno

يمكن مسح صفيفات الأحرف (char[]) بعد الاستخدام من خلال تعيين كل حرف على الصفر والسلاسل لا. إذا تمكن شخص ما من رؤية صورة الذاكرة بطريقة أو بأخرى ، فيمكنه رؤية كلمة مرور بنص عادي إذا تم استخدام السلاسل ، ولكن إذا تم استخدام char[] ، بعد تطهير البيانات باستخدام 0 ، تكون كلمة المرور آمنة.

332
alephx

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

تحديث

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

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

إن أمكن ، فإن تعطيل مقالب أساسية وملف المبادلة يعتني بكلا المشكلتين. ومع ذلك ، فإنها تتطلب حقوق المسؤول وقد تقلل الوظائف (ذاكرة أقل للاستخدام) وسحب RAM لا يزال مصدر قلق صحيح.

206
josefx
  1. السلاسل غير قابلة للتغيير في Java إذا قمت بتخزين كلمة المرور كنص عادي ، فستكون متوفرة في الذاكرة حتى يقوم جامع Garbage بمسحها ، وبما أن السلاسل تُستخدم في String pool من أجل قابليتها لإعادة الاستخدام ، فهناك فرصة كبيرة جدًا لبقائها في الذاكرة لفترة طويلة ، مما يشكل تهديدا أمنيا. حيث يمكن لأي شخص لديه حق الوصول إلى تفريغ الذاكرة العثور على كلمة المرور بنص واضح
  2. توصية Java using getPassword() method of JPasswordField والتي ترجع char [] وطريقة getText() المهملة التي تُرجع كلمة المرور في نص واضح يوضح سبب الأمان.
  3. toString () هناك دائمًا خطر طباعة نص عادي في ملف السجل أو وحدة التحكم ، لكن في حالة استخدام Array ، فلن تطبع محتويات الصفيف بدلاً من ذلك تتم طباعة موقع ذاكرتها.

    String strPwd = "passwd";
    char[] charPwd = new char[]{'p','a','s','s','w','d'};
    System.out.println("String password: " + strPwd );
    System.out.println("Character password: " + charPwd );
    

    سلسلة كلمة المرور: passwd

    كلمة مرور الحرف: [C @ 110b2345

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

135
Srujan Kumar Gulla

لا أعتقد أن هذا اقتراح صحيح ، لكنني على الأقل أخمن السبب.

أعتقد أن الدافع هو التأكد من أنه يمكنك مسح كل تتبع كلمة المرور في الذاكرة على وجه السرعة وبتأكيد بعد استخدامها. من خلال char[] ، يمكنك الكتابة فوق كل عنصر من عناصر المصفوفة باستخدام عنصر فارغ أو شيء مؤكد. لا يمكنك تحرير القيمة الداخلية لـ String بهذه الطريقة.

لكن هذا وحده ليس إجابة جيدة ؛ لماذا لا تتأكد فقط من عدم الرجوع إلى char[] أو String؟ ثم ليس هناك مشكلة أمنية. ولكن الشيء هو أن String_ الكائنات يمكن intern()ed من الناحية النظرية والحفاظ عليها على قيد الحياة داخل المجمع المستمر. أفترض أن استخدام char[] يمنع هذا الاحتمال.

79
Sean Owen

تم تقديم الإجابة بالفعل ، لكن أود مشاركة مشكلة اكتشفتها مؤخرًا مع مكتبات Java القياسية. في الوقت الذي يهتمون فيه الآن باستبدال سلاسل كلمات المرور بـ char[] في كل مكان (وهو أمر جيد بالطبع) ، يبدو أن البيانات الهامة الأخرى المتعلقة بالأمان قد تم تجاهلها عندما يتعلق الأمر بمسحها من الذاكرة.

أنا أفكر في على سبيل المثال PrivateKey class. النظر في سيناريو حيث يمكنك تحميل مفتاح RSA خاص من ملف PKCS # 12 ، واستخدامه لتنفيذ بعض العمليات. الآن في هذه الحالة ، فإن استنشاق كلمة المرور وحدها لن يساعدك طالما أن الوصول الفعلي إلى ملف المفتاح مقيد بشكل صحيح. باعتبارك مهاجمًا ، ستكون أفضل حالًا إذا حصلت على المفتاح مباشرةً بدلاً من كلمة المرور. المعلومات المرغوبة يمكن تسريبها متعددة ، مقالب أساسية ، جلسة مصحح أخطاء أو ملفات المبادلة ليست سوى بعض الأمثلة.

وكما تبين ، لا يوجد شيء يتيح لك محو المعلومات الخاصة بـ PrivateKey من الذاكرة ، لأنه لا يوجد API يتيح لك مسح البايتات التي تشكل المعلومات المقابلة.

هذا وضع سيء ، لأن هذا paper يصف كيف يمكن استغلال هذا الظرف.

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

62
emboss

كما يقول Jon Skeet ، لا توجد طريقة سوى استخدام التفكير.

ومع ذلك ، إذا كان الانعكاس خيارًا بالنسبة لك ، فيمكنك القيام بذلك.

public static void main(String[] args) {
    System.out.println("please enter a password");
    // don't actually do this, this is an example only.
    Scanner in = new Scanner(System.in);
    String password = in.nextLine();
    usePassword(password);

    clearString(password);

    System.out.println("password: '" + password + "'");
}

private static void usePassword(String password) {

}

private static void clearString(String password) {
    try {
        Field value = String.class.getDeclaredField("value");
        value.setAccessible(true);
        char[] chars = (char[]) value.get(password);
        Arrays.fill(chars, '*');
    } catch (Exception e) {
        throw new AssertionError(e);
    }
}

عند التشغيل

please enter a password
hello world
password: '***********'

ملاحظة: إذا تم نسخ حرف [String's char] كجزء من دورة GC ، فهناك فرصة في أن تكون النسخة السابقة في مكان ما في الذاكرة.

لن تظهر هذه النسخة القديمة في ملف تفريغ كومة الذاكرة المؤقتة ، ولكن إذا كان لديك وصول مباشر إلى الذاكرة الخام للعملية ، فيمكنك رؤيتها. بشكل عام يجب تجنب أي شخص لديه مثل هذا الوصول.

47
Peter Lawrey

هذه كلها أسباب ، ينبغي للمرء اختيار char [] صفيف بدلاً من سلسلة لكلمة مرور.

1. نظرًا لأن السلاسل غير قابلة للتغيير في Java ، إذا قمت بتخزين كلمة المرور كنص عادي ، فستكون متوفرة في الذاكرة حتى يقوم جامع Garbage بمسحها ، وبما أن String يُستخدم في تجمع String لإعادة الاستخدام ، فهناك فرصة كبيرة جدًا أن تظل في الذاكرة لفترة طويلة ، مما يشكل تهديدًا أمنيًا.

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

2. توصي Java نفسها باستخدام طريقة getPassword () في JPasswordField والتي تُرجع char [] ، بدلاً من طريقة getText () المهملة التي تُرجع كلمات المرور في نص واضح توضح أسباب الأمان. من الجيد اتباع نصيحة فريق Java والالتزام بالمعايير بدلاً من الالتزام بها.

3. مع String ، يوجد دائمًا خطر طباعة نص عادي في ملف سجل أو وحدة تحكم ، ولكن إذا كنت تستخدم Array ، فلن تطبع محتويات صفيف ، ولكن بدلاً من ذلك تتم طباعة موقع ذاكرتها. وإن لم يكن سبب حقيقي ، فإنه لا يزال من المنطقي.

String strPassword="Unknown";
char[] charPassword= new char[]{'U','n','k','w','o','n'};
System.out.println("String password: " + strPassword);
System.out.println("Character password: " + charPassword);

String password: Unknown
Character password: [[email protected]b053

يشار من هذا بلوق . آمل أن يساعد هذا.

38
Human Being

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

الإجابة الأصلية: ماذا عن حقيقة أن String.equals () يستخدم تقييم دائرة قصر ، وبالتالي عرضة لهجوم توقيت؟ قد يكون ذلك غير مرجح ، ولكن يمكنك {نظريًا تحديد وقت مقارنة كلمة المرور لتحديد التسلسل الصحيح للأحرف.

public boolean equals(Object anObject) {
    if (this == anObject) {
        return true;
    }
    if (anObject instanceof String) {
        String anotherString = (String)anObject;
        int n = value.length;
        // Quits here if Strings are different lengths.
        if (n == anotherString.value.length) {
            char v1[] = value;
            char v2[] = anotherString.value;
            int i = 0;
            // Quits here at first different character.
            while (n-- != 0) {
                if (v1[i] != v2[i])
                    return false;
                i++;
            }
            return true;
        }
    }
    return false;
}

المزيد من الموارد في توقيت الهجمات:

38
Graph Theory

لا يوجد شيء تمنحه char char في مقابل String إلا إذا قمت بتنظيفه يدويًا بعد الاستخدام ، ولم أر أي شخص يقوم بذلك بالفعل. بالنسبة لي ، فإن تفضيل char [] vs String مبالغ فيه بعض الشيء.

نلقي نظرة على تستخدم على نطاق واسع مكتبة Spring Security هنا واسأل نفسك - هي عبارة عن كلمات مرور خاصة بـ Spring Security غير كفء أو كلمة مرور [] لا تعني الكثير. عندما يلتقط بعض المتسللين السيئين مقالب الذاكرة الخاصة بك RAM تأكد من أنها ستحصل على كل كلمات المرور حتى لو كنت تستخدم طرقًا معقدة لإخفائها.

ومع ذلك ، يتغير Java طوال الوقت ، وبعض الميزات المخيفة مثل ميزة إلغاء سلسلة المكررة من Java 8 قد تتدرب على كائنات السلسلة دون علمك. ولكن هذا محادثة مختلفة.

33
Oleg Mikheev

الأوتار غير قابلة للتغيير ولا يمكن تغييرها بمجرد إنشائها. سيؤدي إنشاء كلمة مرور كسلسلة إلى ترك إشارات طائشة إلى كلمة المرور على الكومة أو على تجمع السلسلة. الآن إذا قام شخص ما بتفريغ كومة من عملية Java وقام بمسح دقيق من خلاله ، فقد يكون قادرًا على تخمين كلمات المرور. بالطبع سيتم تجميع هذه السلاسل غير المستخدمة في القمامة ولكن هذا يعتمد على وقت بدء تشغيل GC.

على الجانب الآخر ، تكون char [] قابلة للتغيير بمجرد الانتهاء من المصادقة ، يمكنك الكتابة عليها بأي حرف مثل كل الحروف M أو الخط المائل العكسي. الآن حتى لو قام شخص ما بتفريغ كومة ، فقد لا يتمكن من الحصول على كلمات المرور غير المستخدمة حاليًا. يمنحك هذا مزيدًا من التحكم بمعنى مثل مسح محتوى الكائن بنفسك مقابل انتظار GC للقيام بذلك.

29
Geek

1) نظرًا لأن السلاسل غير قابلة للتغيير في Java إذا قمت بتخزين كلمة المرور كنص عادي ، فسوف تكون متوفرة في الذاكرة حتى يتم مسح أداة تجميع مجمعي البيانات المهملة ولأن String يُستخدم في تجمع String لإعادة الاستخدام ، فهناك فرصة كبيرة جدًا لبقائه في الذاكرة لمدة طويلة ، مما يشكل تهديدا أمنيا. نظرًا لأن أي شخص لديه حق الوصول إلى تفريغ الذاكرة يمكنه العثور على كلمة المرور بنص واضح وهذا سبب آخر يجب عليك دائمًا استخدام كلمة مرور مشفرة بدلاً من النص العادي. نظرًا لأن السلاسل غير قابلة للتغيير ، لا يمكن تغيير محتويات السلاسل لأن أي تغيير سينتج سلسلة جديدة ، بينما إذا كنت [تشار] ، فلا يزال بإمكانك تعيين كل عنصره فارغًا أو صفرًا. لذا فإن تخزين كلمة المرور في صفيف الأحرف يقلل من مخاطر الأمان لسرقة كلمة المرور.

2) توصي Java نفسها باستخدام getPassword () طريقة JPasswordField التي تُرجع char [] وطريقة getText () المهملة التي تُرجع كلمة المرور في نص واضح يوضح سبب الأمان. من الجيد اتباع نصيحة فريق Java والالتزام بالمعايير بدلاً من الالتزام بها.

16
Neeraj Gahlawat

الإجابة القصيرة والمباشرة ستكون لأن char[] قابلة للتغيير بينما الكائنات String ليست قابلة للتغيير.

Strings في Java كائنات ثابتة. هذا هو السبب في أنه لا يمكن تعديلها بمجرد إنشائها ، وبالتالي فإن الطريقة الوحيدة لإزالة محتوياتها من الذاكرة هي جمع القمامة الخاصة بهم. سيكون ذلك فقط عند الكتابة فوق الذاكرة التي تم تحريرها بواسطة الكائن ، وستزول البيانات.

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

باستخدام صفيف character ، يمكنك قراءة كلمة المرور ، والانتهاء من العمل بها بأسرع ما يمكن ، ثم تغيير المحتويات على الفور.

16
Pritam Banerjee

السلسلة غير قابلة للتغيير وتذهب إلى مجموعة الخيط. مرة واحدة مكتوبة ، لا يمكن الكتابة عليه.

char[] عبارة عن صفيف يجب الكتابة فوقه بمجرد استخدام كلمة المرور وهذه هي الطريقة التي يجب القيام بها:

char[] passw = request.getPassword().toCharArray()
if (comparePasswords(dbPassword, passw) {
 allowUser = true;
 cleanPassword(passw);
 cleanPassword(dbPassword);
 passw=null;
}

private static void cleanPassword (char[] pass) {
 for (char ch: pass) {
  ch = '0';
 }
}

أحد السيناريوهات التي يمكن أن يستخدمها المهاجم هو تعطل - عندما يتعطل JVM ويقوم بإنشاء تفريغ ذاكرة - ستكون قادرًا على رؤية كلمة المرور.

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

15
ACV

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

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

بسبب مخاوف الأمان ، من الأفضل تخزين كلمة المرور كصفيف أحرف.

12
Saathvik

إنه أمر قابل للنقاش حول ما إذا كان يجب عليك استخدام String أو استخدام Char [] لهذا الغرض لأن كلاهما لهما مزايا وعيوب. ذلك يعتمد على ما يحتاجه المستخدم.

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

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

استنادًا إلى الظروف المذكورة أعلاه ، يمكن للمرء الحصول على فكرة عما إذا كان سيذهب مع String أو للذهاب مع Char [] لمتطلباتهم.

2
Neeraj

باختصار ، هذا بسبب ما يمكن أن يحدث لكلمة المرور المخزنة بعد انتهائك من استخدامها.

يمكن (في الغالب) أن تبقى السلسلة في الذاكرة لفترة طويلة بعد أن توقفت عن استخدامها ، ولكن يمكن تفريغ صفيف الأحرف بحيث لم يعد يحتوي على بيانات.

كل هذا له علاقة بالطريقة التي يعمل بها جامعو القمامة و الأشياء الثابتة العمل.

0
hamza belmellouki