3

This comes from a security point of view.Best practice says not to use a String to store a password, but a char[]. Does this apply to using a password at any time? For example, it is acceptable to use a String to hold a password when using JDBC?

public final void Login(String username, String password){
...
conn = DriverManager.getConnection(url, username, password);
...
}

Or could a char[] be used here in place of the String?

user3055593
  • 69
  • 1
  • 8
  • You shouldn't use a String to ever hold sensitive data because of the way that Strings are stored in Java. char[] will in general be SAFER. – Kon Dec 03 '13 at 03:35
  • 1
    "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". But I don't know how to use char[] in place of string in the example i gave. – user3055593 Dec 03 '13 at 03:40
  • It's important that you decide if you mean *password* or *key*. A *password* is generally character data and is best represented as a string. A *key* is binary data and should be an array of byte or something similar. – Hot Licks Dec 03 '13 at 03:41
  • 2
    @Kon - The "safety" difference between a String and a char[] is microscopic. Their internal representations are essentially identical. – Hot Licks Dec 03 '13 at 03:44

2 Answers2

3

I don't know that I accept your premise that a char [] is more secure than a String in the context of a system(s) resource (e.g. JDBC database connection). Regardless, you can use a connection manager (or connection pool, whichever is appropriate to your container) and then the connection manager (and only the connection manager) has visibility to the underlying databse username / password.

Elliott Frisch
  • 198,278
  • 20
  • 158
  • 249
  • 3
    "I don't know that I accept your premise that a char [] is more secure than a String" You should. Array elements can be overwritten, a string is stored in the string pool. – Jeroen Vannevel Dec 03 '13 at 03:41
  • 1
    There are lot of articles on why NOT String for passwords. Better review them. – kosa Dec 03 '13 at 03:42
  • 3
    If it's loaded at runtime, and accessed by user-code... how secure can it be? – Elliott Frisch Dec 03 '13 at 03:43
  • 3
    @JeroenVannevel - yes, char[] can in theory be overwritten. also, it can be copied around to various memory pools before it is overwritten, thus making the overwriting pointless. if something has access to the jvm memory, you have already lost all security... – jtahlborn Dec 03 '13 at 04:09
  • @jtahlborn So if it's possible to do it wrong, don't do it at all? Of course it's possible to make such a thing completely pointless. But if monitored correctly, does give a security boost over `String`. Not only due to the pool, but due to a `String`, albiet unreachable, looming in memory until the GC sweeps it. Depending on the implementation, this could be a while, as some implementations only execute when memory is actually needed. – Vince Jul 07 '15 at 23:57
  • 1
    @VinceEmigh - you misunderstood what i was saying. i wasn't saying the user could mess it up in various ways, i'm saying the _jvm_ could mess it up in various ways (read up on modern GC implementations in the jvm). i'm saying that using developer time and energy using char[] instead of String is wasted resources because in reality they are both just as "secure". – jtahlborn Jul 08 '15 at 00:21
  • 2
    @jtahlborn …and the optimizer can eliminate writes that are never followed by a read… – Holger Jan 06 '20 at 16:01
1

String in java is immutable, once you create it, it can't be changed and thus whenever we say String s="abc"; s="def"; they do not refer to same string, instead it creates "abc" string object, s refers to it and when we say s="def", another string object "def" is created referred by s, and thus abandoning "abc".

So "abc" is left in the heap, and now suppose this is some highly secure password floating in heap just waiting to be accessed by some wrong party.

that is why it is encouraged to use char[] for password.

there are other alternatives like StringBuffer too.

Amrit
  • 11
  • 2
  • But unless you're foolish enough to intern it, a String is GCed as quickly as an array. (In fact, a String *is* an array, with a few extra fields.) – Hot Licks Dec 03 '13 at 12:32
  • @HotLicks Java 1.8.20 introduced String deduplication which essentially interns your String without you doing anything. – Ryan Jun 01 '15 at 22:18
  • 1
    @Ryan string deduplication, as its name suggests, is only relevant if you have *duplicate* strings, in other words, not only one existing string, but at least two of them. There is no relevance to a string that is about to be garbage collected. – Holger Jan 06 '20 at 15:56
  • 1
    @HotLicks actually, it doesn’t matter whether you call `intern()` on it. It still gets garbage collected as soon as an ordinary array. But in either case, getting collected doesn’t imply that its memory gets overwritten. Of course, writing `"password"` into your code is a different beast, as the character data would even exist in memory when no string has been created, as part of the class data. – Holger Jan 06 '20 at 16:00