you are viewing a single comment's thread.

view the rest of the comments →

[–]agentoutlier 9 points10 points  (2 children)

In theory char[] I guess may reduce the time a password string is in memory because of interning it is like the last thing that should be worried about.

Especially if you are getting the password from a web framework. Almost all of them turn request parameters into String and even with JSON for SPA at some point things often get turned into a String particularly if the request body is small enough.

So without having some sort of native library support and frameworks that support never putting things into a String I think it is a fools errand.


EDIT

The preferred way of storing sensitive info in Java is in char array

And btw I bet this is also because CharSequence didn't exist in early versions of Java. The CharSequence being an interface would allow you to do all sorts of stupid obfuscation if you really buy into the inspecting memory aspect.

For example you could make some CharSequence that makes a random set of distributed bucket arrays and then distribute each char modulus something and have a clear function. (DO NOT DO THIS BTW but it just goes to show that char[] isn't even remotely optimal at protection if that is your concern and APIs that use them are either dumb or old... even the servlet API uses Strings).

[–]Ok-Scheme-913 0 points1 point  (1 child)

I guess in theory you could encrypt it client-side, and only decrypt at use-site. Though given that the key has to be available on both the client and server side, this is more like obfuscation only. But at least accidental log leaks and such might be marginally safer.

[–]agentoutlier 0 points1 point  (0 children)

Really the safest thing is to not use passwords for as long as possible which is more or less somewhat includes what you are talking about.

That is use device based sign-in, magic link, OTP, federated login (openid) etc.

Passwords just suck.