How do I send a password without using String from java to postgresql?

I know that char[] is preferable over String when it comes to passwords, due to the fact that String is immutable. But I have not been able to figure out how to pass it to a prepared statement. Consider this code:

Connection con = MyDBManager.connect();
PreparedStatement stm = con.prepareStatement(
    "INSERT INTO my_table(username, password) VALUES(? ?)");
String username = "Jonny";
stm.setString(username);
char[] password = new char[] {'a','b','c','d'};
stm.SetString(password.toString());

It works, but I suspect calling password.toString() defeats the whole purpose of using a char[], so how should I do?

And yes, I know that a password should not be stored in clear text. The password is hashed, but I still want to use the benefits of a char[]

This seemed to work, and I also changed the field in the database from text to bytea and (I think) should in theory give the same benefits as the char[] is supposed to, but I get a strong feeling that I'm not doing it right:

byte[] password = new byte[] {'a','b','c','d'};
stm.SetBytes(password);

Maybe I'm completely wrong in my approach, but my requirements are that the password hash should never exist in an immutable object. I am open to other ways of sending it to the database than PreparedStatement

Answer to comments:

I have learned a lot from @rzwitserloot's answer, but unfortunately it does not help. Never having the password hash in an immutable object is a non-negotiable requirement.

Why are passwords in char[] form?

> I know that char[] is preferable over String when it comes to passwords, due to the fact that String is immutable.

If you mean: So now you can't change passwords. That's incorrect.

Perhaps you are referring to the fact that you can't wipe them clean', but just in case you aren't, let me explain that:

There is only one reason that char[] is preferable over String, and it is highly dubious: With a char[], you can 'wipe' the array out. That is, once your process (your java code) no longer needs the password, you can explicitly run Arrays.fill(thePassword, (char) 0); and now RAM no longer contains the password. You can't do this with string - you can null out your reference, but that's just 'wiping out the treasure map'. It's not digging up the treasure and smashing the treasure to bits. Someone willing to dig up the entire beach is still going to find it.

This sounds great, and is the only explanation for why a whole bunch of password-based APIs deal in char[] and not String. HOWEVER, this is extremely dubious as a principle and you should absolutely not rely on it:

• If some other process that you cannot trust has access to your process's memory you are quite hosed already. You should fix that at the source, and not try to mitigate this problem by reducing your exposure. That's akin to having a giant gaping hole in your artery and fixing it by hooking up a constant supply of blood bags (fighting symptoms) instead of bandaging the wound (closing the actual hole). If somehow the hole cannot be closed, I guess the symptom fighting is better than nothing, but it's a poor alternative.
• You have no actual guarantee, between OS and CPU caches, that wiping out your char array gaurantees that the password is no where in any part of the hardware that a hacker could feasibly get at.

For what it is worth, I would not judge any code that stores strings in passwords as insecure. In fact, I dread code that stores them in char[] form - I fear that the authors will misunderstand the protection that this gives, or that they straight up forget to zero it out: It's making readers of the code make false presumptions (namely, that the password is wiped out, which may not be true, and that this means that the password is not recoverable if anything manages to get a dump of the memory contents, which also probably isn't true).

NB: With security it's a good idea to get into the habit of writing James Bond film scripts. Here's a film script for you:

You run your server in a cloud hosting environment, on a virtualized PC. The operator of this cloud messed up, and upon server deletion (which is really just the termination of a virtual PC running on a host that is running hundreds of PCs), they do not wipe out the memory of the process. Somebody decides to try to abuse this: They ask the cloud hoster to give them a PC with linux on it, they then install a simple app that scans the virtual PC's own memory for anything that looks like a password and reports back, then shuts the machine down and terminates it, and asks for another one.

By using char[] AND wiping out the password, you're more safe against this.. but not if the server just crashes or gets hard-killed _which is exactly how e.g. Amazon EC2 is supposed to be used (see netflix's chaos monkey documentation, which the community at large generally agrees is the right way to do things), in which case there's a risk some password just so happened to be in char[] phase. Not to mention all the other places in memory these can end up in.

See how bond-level scripts help clarify matters? It shows there is SOME point to wiping out char arrays, but it's not foolproof.

How do I store a password in postgres

hashing it is also no good. At least, depending on what you mean with the word 'hash'.

The proper approach involves 2 things:

• A 'salt' - the problem is, a LOT of people have iloveyou as a password. It doesn't matter what hashing algorithm you use, hashing algorithms by their nature hash the same input to the same output, so all I need to do if I get a complete dump of your DB is to run SELECT passhash, COUNT(*) AS ct FROM accounts GROUP BY passhash ORDER BY ct DESC LIMIT 1, and voila - that hash? That's iloveyou, and I can then do SELECT username FROM accounts WHERE passhash = ?, and everybody in that list? I can log in as them with pass iloveyou. Simple as that. A salt solves this problem: the idea is, you generate a random number for every account (upon account creation), you then store this random number in the database. The hash you store is the result of hashing the value: CONCATENATE(salt, password). Now every user that is an idiot and uses iloveyou as password ends up with a different hash. To check a password, you take the password as entered, retrieve the salt, recreate CONCAT(salt, pass), hash that, and confirm it matches the DB entry.

• You want a hashing algorithm that is slow and weird. SHA-256, for example, is used by bitcoin, so there are a ton of dedicated machines out there that can generate billions of hashes a millisecond for SHA-256, and there's specialized hardware out there (hardware you don't have) that is far faster at it than any computer you own. That's bad, you don't want the hacker to have an advantage. So, you want a hash algo that is really slow, and is not (easily) optimized for custom hardware. BCrypt, SCrypt, and PBKDF are the commonly used variants for this. They're all fine (BCrypt is older and in that sense 'worse', but also simpler and proven. Pick whichever one you want).

• Note that most libraries out there will take care of the whole salt business already, no need to explicitly generate and store these (the APIs of these libraries are simply: "Give me a thing to put in a DB for this password" and "The user entered this password, and this is the thing you told me to put in the DB earlier. Is it a match?". 'The thing to put in the DB' contains both the salt and the hash result combined into a single string.

Okay, so how do I get this 'thing to put in DB' that the bcrypt lib gave me to postgres?

It's going over a wire or at least a local socket, into the postgres WAL log, which then goes everywhere. The thing is also literally right there in the DB.

The notion that you can somehow eliminate this hashes value from your system hardware is completely impossible.

So just make a java.lang.String. It's fine.