How to store server password in Java client for later reconnects?

Question

I have a client application that connects to a server over a secure/SSL socket. The user is required to log in when the app starts. Right now I have a requirement that I need to send the actual password to the server (encrypted over the SSL), instead of the preferred method of sending a hash of the password. With that said, how do I go about securely storing the password in the client memory such that I can re-use this password if the client needs to reconnect to the server behind the scenes due to a lost connection?

I can easily encrypt the password, or even put it into a KeyStore and retrieve it later for the reconnect, however, even if I do this, it seems to me a hacker could retrieve the password if he had access to the application in a debugger. Is this just a fact of life when one needs to store the password on the client for a temporary time?

Is there a better/preferred way of achieving the same thing (i.e. allowing the client to reconnect to the server without requiring the user to enter his password again after the initial login)? Would an expiring login token sent from the server be a better way to go (where I can pass this expiring token back to the server instead of a password upon a reconnect)?

Finally, in general, how easy is it for someone to connect a debugger to a running application on Java desktop or Android, when the Application is correctly 'stripped' of debugging symbols? Do I even need to worry about this case, or will Java protect my shipping application from having a debugger, or other memory analyzer, attach to it?

Answer 1

a hacker could retrieve the password if he had access to the application in a debugger.

Correct. The hacker also has access to the password when they watch the user type by looking over the user's physical shoulder with their physical eyeballs.

And the hacker has access after they store a keylogger on the users computer.

Is this just a fact of life when one needs to store the password on the client for a temporary time?

No.

The alternative is for you to personally visit each user and tell them not to use the debugger to break security.

Let's just think about the use case where the user (who knows the password) fires up the application in a debugger to learn the password. Which they already knew.

After thinking about the only use case in which the user fires up the client application running under a debugger, I'm not sure security is "broken", since they already knew the password.

I guess it would be possible for Henry Hacker to start the app in the debugger, conceal that on another display by turning the power off, then running to get the real user and having them type in their password on a development workstation that has one of the monitors turned off. Is that the "access to the application in a debugger" scenario you're talking about?

Do I even need to worry about this case,

Not really

or will Java protect my shipping application from having a debugger, or other memory analyzer, attach to it?

No, Java doesn't protect your users. Common sense protects your users.

If a debugger is running, they shouldn't be using the computer.

And 99% of the time, they won't get a debugger started.

1% of the time, they'll accidentally run a debugger -- because users click random icons. Of those 1% will actually get your application to run under the debugger. Again, by clicking random icons. Of those 1% will actually get to the place where they could type in a password by clicking random icons on the screen.

It could happen that a user could somehow run your client under a debugger. But. Since they already know the password, there's little point in worrying about it.

---

This is entirely different from a man-in-the-middle attack or a remote control attack.

If someone takes remote control of your user's computer, runs the debugger, and watches the transaction, that's entirely separate. That's stopped by firewalls and operating systems. Not Java.

---

put it into a KeyStore and retrieve it later for the reconnect

That's all you can ever do. The "connect a debugger" scenario cannot be prevented by your applications. It's the OS's job to alert the user that a debugger is being connected.

If you're worried about liability, don't store passwords. End of liability.