Representing passwords as char[] is a weak argument. Manny of these char[] arrays are going to have to stay in memory in some form usually anyways. For example, a browser app may not keep a password in memory, but it sure as hell will keep a session cookie in memory which is just as big of a security hole. Passwords used to continually access the same resources (DB connections, etc.) also have to remain in memory unless you want to hit persistent storage each and every time. The mechanisms to obtain a password from a user are often already String based. Plus, there's no guarantee a memory swap isn't going to happen when the password char[] is in memory anyways. Finally, if you're running a secure system on an insecure box then you deserve your fate.

On 12/7/2012 9:20 AM, Darran Lofthouse wrote: > Reading this a lot of your justification appears to be that there are > other weak areas that also need to be addressed so lets address them > rather than using them as a justification. > > Relying on a session token to identify a remote user is weak security, > no stronger than authenticating using plain text passwords. > Most apps that run on Tomcat, Jetty, and JBossWeb use a session cookie. Also, How safe is SSL from this type of memory dump attack? Does it not have to keep the private key(s) in memory? > Having to have some passwords in memory may be an indication that some > of those also need to be reduced but don't see how it justifies keeping > more in memory. > If you only fix one hole in a leaky roof, you still have a leaky roof. It is impossible to protect against this attack because you have no control when a swap happens let alone all the areas that must store credentials in memory over a long period. It is the responsibility of the OS to protect against this attack, not the JVM. This is very much like how people continually try to emulate SSL features with their own leaky protocols, when if they just used SSL to begin with they wouldn't have those leaks. > And regarding users that deserve their own fate we have been there, done > that and moved beyond that now - that really is the pre-Red Hat approach > we used to have. > I disagree. This is one problem that can only *fully* be solved at the OS level. Since we are now post-Red Hat we actually have an OS as part of our portfolio, so we should delegate responsibility to RHEL where appropriate. This is one of those situations.