Why is char preferred over String for passwords

Question

In Swing  the password field has a getPassword    returns char    method instead of the usual getText    returns String  method  Similarly  I have come across a suggestion not to use String to handle passwords   Why does String pose a threat to security when it comes to passwords  It feels inconvenient to use char

User · Answer

Character arrays  char    can be cleared after use by setting each character to zero and Strings not  If someone can somehow see the memory image  they can see a password in plain text if Strings are used  but if char   is used  after purging data with 0 s  the password is secure

User · Answer

Strings are immutable and cannot be altered once they have been created  Creating a password as a string will leave stray references to the password on the heap or on the String pool  Now if someone takes a heap dump of the Java process and carefully scans through he might be able to guess the passwords  Of course these non used strings will be garbage collected but that depends on when the GC kicks in   On the other side char   are mutable as soon as the authentication is done you can overwrite them with any character like all M s or backslashes  Now even if someone takes a heap dump he might not be able to get the passwords which are not currently in use  This gives you more control in the sense like clearing the Object content yourself vs waiting for the GC to do it

User · Answer

Case String       String password    ill stay in StringPool after Death              some long code goes           Now I want to remove traces of password     password   null      password              above attempts wil change value of password        but the actual password can be traced from String pool through memory dump  if not garbage collected   Case CHAR ARRAY       char   passArray     p   a   s   s   w   o   r   d           some long code goes           Now I want to remove traces of password     for  int i 0  i lt passArray length i             passArray i     x                Now you ACTUALLY DESTROYED traces of password form memory

User · Answer

Strings are immutable  That means once you ve created the String  if another process can dump memory  there s no way  aside from reflection  you can get rid of the data before garbage collection kicks in   With an array  you can explicitly wipe the data after you re done with it  You can overwrite the array with anything you like  and the password won t be present anywhere in the system  even before garbage collection   So yes  this is a security concern - but even using char   only reduces the window of opportunity for an attacker  and it s only for this specific type of attack   As noted in the comments  it s possible that arrays being moved by the garbage collector will leave stray copies of the data in memory  I believe this is implementation-specific - the garbage collector may clear all memory as it goes  to avoid this sort of thing  Even if it does  there s still the time during which the char   contains the actual characters as an attack window

User · Answer

These are all the reasons  one should choose a char   array instead of String for a password   1   Since Strings are immutable in Java  if you store the password as plain text it will be available in memory until the Garbage collector clears it  and since String is used in the String pool for reusability there is a pretty high chance that it will remain in memory for a long duration  which poses a security threat    Since anyone who has access to the memory dump can find the password in clear text  that s another reason you should always use an encrypted password rather than plain text  Since Strings are immutable there is no way the contents of Strings can be changed because any change will produce a new String  while if you use a char   you can still set all the elements as blank or zero  So storing a password in a character array clearly mitigates the security risk of stealing a password   2   Java itself recommends using the getPassword   method of JPasswordField which returns a char    instead of the deprecated getText   method which returns passwords in clear text stating security reasons  It s good to follow advice from the Java team and adhere to standards rather than going against them   3   With String there is always a risk of printing plain text in a log file or console but if you use an Array you won t print contents of an array  but instead its memory location gets printed  Though not a real reason  it still makes sense   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   C 110b053   Referenced from this blog  I hope this helps

User · Answer

It is debatable as to whether you should use String or use Char   for this purpose because both have their advantages and disadvantages  It depends on what the user needs   Since Strings in Java are immutable  whenever some tries to manipulate your string it creates a new Object and the existing String remains unaffected  This could be seen as an advantage for storing a password as a String  but the object remains in memory even after use  So if anyone somehow got the memory location of the object  that person can easily trace your password stored at that location   Char   is mutable  but it has the advantage that after its usage the programmer can explicitly clean the array or override values  So when it s done being used it is cleaned and no one could ever know about the information you had stored   Based on the above circumstances  one can get an idea whether to go with String or to go with Char   for their requirements

User · Answer

To quote an official document  the Java Cryptography Architecture guide says this about char   vs  String passwords  about password-based encryption  but this is more generally about passwords of course       It would seem logical to collect and store the password in an object   of type java lang String  However  here s the caveat  Objects of   type String are immutable  i e   there are no methods defined that   allow you to change  overwrite  or zero out the contents of a String   after usage  This feature makes String objects unsuitable for   storing security sensitive information such as user passwords  You   should always collect and store security sensitive information in a   char array instead    Guideline 2-2 of the Secure Coding Guidelines for the Java Programming Language  Version 4 0 also says something similar  although it is originally in the context of logging       Guideline 2-2  Do not log highly sensitive information      Some information  such as Social Security numbers  SSNs  and   passwords  is highly sensitive  This information should not be kept   for longer than necessary nor where it may be seen  even by   administrators  For instance  it should not be sent to log files and   its presence should not be detectable through searches  Some transient   data may be kept in mutable data structures  such as char arrays  and   cleared immediately after use  Clearing data structures has reduced   effectiveness on typical Java runtime systems as objects are moved in   memory transparently to the programmer       This guideline also has implications for implementation and use of   lower-level libraries that do not have semantic knowledge of the data   they are dealing with  As an example  a low-level string parsing   library may log the text it works on  An application may parse an SSN   with the library  This creates a situation where the SSNs are   available to administrators with access to the log files

User · Answer

Some people believe that you have to overwrite the memory used to store the password once you no longer need it  This reduces the time window an attacker has to read the password from your system and completely ignores the fact that the attacker already needs enough access to hijack the JVM memory to do this  An attacker with that much access can catch your key events making this completely useless  AFAIK  so please correct me if I am wrong    Update  Thanks to the comments I have to update my answer  Apparently there are two cases where this can add a  very  minor security improvement as it reduces the time a password could land on the hard drive  Still I think it s overkill for most use cases    Your target system may be badly configured or you have to assume it is and you have to be paranoid about core dumps  can be valid if the systems are not managed by an administrator    Your software has to be overly paranoid to prevent data leaks with the attacker gaining access to the hardware - using things like TrueCrypt  discontinued   VeraCrypt  or CipherShed    If possible  disabling core dumps and the swap file would take care of both problems  However  they would require administrator rights and may reduce functionality  less memory to use  and pulling RAM from a running system would still be a valid concern

User · Answer

As Jon Skeet states  there is no way except by using reflection    However  if reflection is an option for you  you can do this   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             when run  please enter a password hello world password                  Note  if the String s char   has been copied as a part of a GC cycle  there is a chance the previous copy is somewhere in memory     This old copy wouldn t appear in a heap dump  but if you have direct access to the raw memory of the process you could see it   In general you should avoid anyone having such access

User · Answer

Edit  Coming back to this answer after a year of security research  I realize it makes the rather unfortunate implication that you would ever actually compare plaintext passwords  Please don t  Use a secure one-way hash with a salt and a reasonable number of iterations  Consider using a library  this stuff is hard to get right   Original answer  What about the fact that String equals   uses short-circuit evaluation  and is therefore vulnerable to a timing attack  It may be unlikely  but you could theoretically time the password comparison in order to determine the correct sequence of characters   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      Some more resources on timing attacks    A Lesson In Timing Attacks A discussion about timing attacks over on Information Security Stack Exchange And of course  the Timing Attack Wikipedia page

User · Answer

The short and straightforward answer would be because char   is mutable while String objects are not   Strings in Java are immutable objects  That is why they can t be modified once created  and therefore the only way for their contents to be removed from memory is to have them garbage collected  It will be only then when the memory freed by the object can be overwritten  and the data will be gone   Now garbage collection in Java doesn t happen at any guaranteed interval  The String can thus persist in memory for a long time  and if a process crashes during this time  the contents of the string may end up in a memory dump or some log    With a character array  you can read the password  finish working with it as soon as you can  and then immediately change the contents

User · Answer

I don t think this is a valid suggestion  but  I can at least guess at the reason   I think the motivation is wanting to make sure that you can erase all trace of the password in memory promptly and with certainty after it is used  With a char   you could overwrite each element of the array with a blank or something for sure  You can t edit the internal value of a String that way   But that alone isn t a good answer  why not just make sure a reference to the char   or String doesn t escape  Then there s no security issue  But the thing is that String objects can be intern  ed in theory and kept alive inside the constant pool  I suppose using char   forbids this possibility

User · Answer

String in java is immutable  So whenever a string is created  it will remain in the memory until it is garbage collected  So anyone who has access to the memory can read the value of the string   If the value of the string is modified then it will end up creating a new string  So both the original value and the modified value stay in the memory until it is garbage collected    With the character array  the contents of the array can be modified or erased once the purpose of the password is served  The original contents of the array will not be found in memory after it is modified and even before the garbage collection kicks in  Because of the security concern it is better to store password as a character array

User · Answer

While other suggestions here seem valid  there is one other good reason  With plain String you have much higher chances of accidentally printing the password to logs  monitors or some other insecure place  char   is less vulnerable   Consider this   public static void main String   args        Object pw    Password       System out println  String      pw        pw    Password  toCharArray        System out println  Array      pw       Prints   String  Password Array   C 5829428e

User · Answer

The answer has already been given  but I d like to share an issue that I discovered lately with Java standard libraries  While they take great care now of replacing password strings with char   everywhere  which of course is a good thing   other security-critical data seems to be overlooked when it comes to clearing it from memory   I m thinking of e g  the PrivateKey class  Consider a scenario where you would load a private RSA key from a PKCS 12 file  using it to perform some operation  Now in this case  sniffing the password alone wouldn t help you much as long as physical access to the key file is properly restricted  As an attacker  you would be much better off if you obtained the key directly instead of the password  The desired information can be leaked manifold  core dumps  a debugger session or swap files are just some examples   And as it turns out  there is nothing that lets you clear the private information of a PrivateKey from memory  because there s no API that lets you wipe the bytes that form the corresponding information   This is a bad situation  as this paper describes how this circumstance could be potentially exploited   The OpenSSL library for example overwrites critical memory sections before private keys are freed  Since Java is garbage-collected  we would need explicit methods to wipe and invalidate private information for Java keys  which are to be applied immediately after using the key

User · Answer

There is nothing that char array gives you vs String unless you clean it up manually after use  and I haven t seen anyone actually doing that  So to me the preference of char   vs String is a bit exaggerated   Take a look at the widely used Spring Security library here and ask yourself - are Spring Security guys incompetent or char   passwords just don t make much sense  When some nasty hacker grabs memory dumps of your RAM be sure s he ll get all the passwords even if you use sophisticated ways to hide them   However  Java changes all the time  and some scary features like String Deduplication feature of Java 8 might intern String objects without your knowledge  But that s a different conversation

User · Answer

String is immutable and it goes to the string pool  Once written  it cannot be overwritten   char   is an array which you should overwrite once you used the password and this is how it should be done   char   passw   request getPassword   toCharArray   if  comparePasswords dbPassword  passw     allowUser   true   cleanPassword passw    cleanPassword dbPassword    passw null     private static void cleanPassword  char   pass     Arrays fill pass   0        One scenario where the attacker could use it is a crashdump - when the JVM crashes and generates a memory dump - you will be able to see the password   That is not necessarily a malicious external attacker  This could be a support user that has access to the server for monitoring purposes  He could peek into a crashdump and find the passwords

[java] Why is char[] preferred over String for passwords?

Examples related to java

Examples related to string

Examples related to security

Examples related to passwords

Examples related to char