1

I'm using SparkJava and I'm conserned when dealing with Passwords. The idea is to pass the password (in plain text) to the server (under https obviously), then hash and salt server side, and store the salt and hash on the server for the user. However according to this post the plain text password should never be stored as a String in memory for security reasons.

However when accessing the http protocol body from a POST request using SparkJava, the API returns a String, which has the plaintext password. 

Route post = (request, response) -> {
    String dataWithPassword = request.body();
    //     ^-- Stays in memory until GC kicks in 
}

How should I do to make sure that the plaintext password that was received from a client is not stored as a String serverside, so this might never be a potential security hole? Or is there something else I can do to make sure that the memory is cleared and the plaintext password doesn't linger in memory?

Community
  • 1
  • 1
Gronis
  • 116
  • 1
  • 6

1 Answers1

0

The way you are doing it's already guaranteed that this password will never be stored in a file, like a server log. But in Java there's no official way to clear the memory. There's nothing you can do to guarantee that the memory that holds the plain text password is cleared. You could even set the reference dataWithPassword to null and call System.gc() which suggest that now is a good time to run the garbage collector, but it would not be guaranteed to get that memory cleared. I see that a possible security issue in your approach is to send the password in plain text from the client to the server, even by using https (I strongly not suggest this). The best thing you could do is to require the client o give you the password already encrypted, so that you wouldn't need to worry about this value in memory and you're going to get a lot more safety cause network sniffers and proxies would not now what the password is.

Laercio Metzner
  • 1,351
  • 11
  • 22
  • I thought that HTTPS would ensure that the whole HTTP protocol is encrypted. Is this not the case? How do you suggest that I encrypt the password? I have to use JavaScript to encrypt client side, and Java on the server side. I do not see why HTTPS (using TLS) is not enough encryption. – Gronis Apr 18 '16 at 20:32
  • Unfortunetly https doesn't guarantee 100% of safety itself. Do a quick google search on "https security issues". And yes, you can use Javascript for client side encription. – Laercio Metzner Apr 18 '16 at 22:55
  • According to this SO post http://security.stackexchange.com/questions/33793/handling-passwords-in-a-web-application, just using HTTPS is the preferred way. Also, lets say HTTPS is not secure, the way to fix it would not be to implement a javascript library and make up your own security protocol how to communicate, because this protocol will most likely have security issues. A better way of doing it is to update the security standard (SSL/TLS) which was last updated in 2011. Are you sure that TLS RFC 6176 is insecure? – Gronis Apr 19 '16 at 19:34
  • The right answer of [this question](http://security.stackexchange.com/questions/4936/what-to-transfer-password-or-its-hash) has a comment that in my opinion is already a good reason for client encryption. I cannot tell you how safe using only https would be, but I keep saying that with some client side obfuscation would be still better. That's a personal opinion. – Laercio Metzner Apr 21 '16 at 18:48
  • Ok there seems to be many suggestions whether or not to hash on the client side. I got a better understanding now how I might do. Thanks for your time! – Gronis Apr 21 '16 at 20:14