0

My Java app server is about to integrate with a RESTful web service and will be polling it for content (JSON) to display to my users.

My users login with their usernames/passwords, which I must then hash + salt and then forward on to the web service with each call. The web service takes the hashed/salted login info and authenticates it (again, each call).

Assuming that I can't change anything on the web service end, and that the webservice expects hashed/salted login credentials as input parameters (along with the API endpoint, HTTP body, etc.), what are some security measures I can take on the client-side to keep the user-supplied username/password safe.

The worst thing I could probably do is just keep them in memory. What are my other options?

smeeb
  • 22,487
  • 41
  • 197
  • 389

1 Answers1

1

The main question is "against what do you want protection". Your user already know they username and passwords, so you can consider that keeping them client side is mostly secure (at least, you don't need to protect those credentials against the user). The salted + hashed password can be used as credential against the web service, so they have the same value as a username / password. Your user already send its password to your server, so implicitly, it already trust your server.

Conclusion : keeping hashes directly in memory is fairly safe in this context.

To limit risk, you should probably not store this hash in permanent storage (database, file on disk, ...).

If you want to ensure that your application stay stateless, it is not a bad idea to store this hash on the client itself (in a cookie). We might argue that this reduce the security somewhat, as it is opens the hash to client side attacks as well.

What's the real problem here ?

The real problem, is that the client needs to trust your server, so you need to take the burden of ensuring that trust is kept. That's why solutions like OpenId are interesting : they limit the trust given to a third party.

Guillaume
  • 17,054
  • 8
  • 51
  • 73