Question

I’m currently working on an application consisting both of a webapplication and client software. The client communicates via webservices, supporting both a SOAP and Protobuffer implementation.

The initial registration is done via the webapplication, which relies on username + password authentication later on.

After finishing the registration process, all features are also available via the client, which will only communicate via HTTPS. For authenticating webservice calls, I’m currently thinking about three possible approaches:

1. Including the username and password in every message. But is it really a good practice to include the credentials in every request, even though secured by HTTPS?

2. Providing the username and password in the first webservice request. The client then gets a token which is used for all future requests. (Note: It’s not deemed acceptable to force the user to copy a server-generated token to the client application.) Only if the user revokes the token, he needs to send his username and password again for getting a new token. Such token based approaches seem to be quite common, for example Google, AWS and Rackspace are using them a lot. But does it really pay off in this scenario?

3. Hashing the password on the client sounds like a good solution. However I’d like to salt the encrypted passwords on the server-side. Adding requests only for fetching salts doesn’t sound like an optimal solution or is it?

Are there any best practices or tips? I couldn’t find too much information exactly for these requirements.
Currently I’d go with 2), but I’m not really convinced yet.

The project is based on Java, Apache CXF, Protobuffers and Shiro, but shouldn’t have too much of an impact for the general question…

Answer 1

If you’re only concerned by authentification and neither by confidentiality nor integrity, you can handle it by securing:

• HTTP transport level, using HTTP BasicAuth (user+password on each message) + eventually HTTPS for confidentiality, however as you noticed (solution 1) it it is kind of old school and keeping user/password in local cache is not a big deal but cannot be advised.
• Message level (the soap message) using Security Token for instance but I do not know Protobuffer
• Application level (solution 2 and 3), that is the way Google, Amazon, Ebay and others are working. You will not ask the user to copy/paste his token, you will generate one from user/password

I would securing the application level using a token, since getting a salt from the server is almost like getting a token and does not add more security (a secured salt should be known from only you, and if channel is protected it mean getting the token from given password and username is secured as well).

A better but more complex solution would be usage of SSL certificates, available both in browser and client software.