HMAC/PBKDF2 vs Simple hashing algorithm for web service authentication?

Question

We are in the process of creating a web service and have been investigating ways of securing it. In reality, the service is likely to get very little traffic and the data is likely to be of little use to anyone. However, we will need to authenticate users and do what we can to ensure the integrity of the data passed to the service.

Therefore, we've looked at using HMAC with the key being a 256 bit key derived from the users password entered on the client using PBKDF2. While I'm happy thus far with our implementation, I'm not sure how PBKDF2 with even 1000 iterations will perform on a iPhone/Android client. Also, as I mentioned earlier, it is unlikely anyone would want to compromise our service and while reading questions such as this one that mention things like "threat model and risk profile", I wonder if I am overdoing things.

The thing is, a third party has been commissioned to develop the client application, and their initial design doc provides some basic thinking of their idea of security and it is much more around something like;

MD5(shared secret + user password + request uri + timestamp + json serialised post data (if any))

Irrespective of whether we choose MD5, SHA1, or SHA256 is there any advantage to choosing HMAC/PBKDF2 over their suggested method (assuming roughly the same inputs to generate the hash)? Basically, am I overcomplicating this for a service that is likely to see a very small amount of traffic? At this stage, it is likely that all traffic will be over SSL also.

Answer 1

Recommended approach. I recommend that you use SSL and authenticate the client using their password. Then you won't need any fancy MAC, hash, PBKDF2, etc.

Details. You asked how to authenticate the user. Here is a simple approach. Use SSL sitewide. When the user logs in (entering their password in via a web client), then set a session cookie that remembers the user for the rest of their session. (Make sure to use SSL throughout, and to set the secure flag on all cookies.) If you want, you can set a persistent secure cookie once the user authenticates, so they will never need to enter their password again on this browser.

If you want to access the web service from a dedicated mobile client, the same approach works fine. The web server can send a secure persistent cookie which the app can store permanently in its app-local storage, and can use that cookie to authenticate the client.

Alternatives. If for some reason the above is not possible, there are some fallback alternatives, but I think they are less preferable and more likely to have security problems. Here's one plausible fallback method:

• On the first launch of your mobile client app, it prompts the user for their password, connects to the server over SSL, and sends the password over SSL. The server responds with a random 128-bit authentication key (chosen by the server using a crypto-strength PRNG).

• The client app stores this auth key permanently in app-local storage. The server remembers the association between this auth key and the user's account permanently.

• All future requests from the client app are authenticated using this auth key, as follows: you append a parameter to the end of the URL that holds the HMAC (under the auth key assigned to this client) of the rest of the URL, any POST data, and any other state that the server will taken into account.

As long as all requests are idempotent (e.g., for non-idempotent actions, you make sure to include a unique identifier somewhere in the URL parameters or in the POST data, and the server does replay detection), this should work OK to protect the authenticity and integrity of requests from the client to the server.

However, it has some security limitations. It does not protect confidentiality. It also does not protect other request headers, response data, and all sorts of other stuff. For this reason, it is not as secure as just using SSL. For instance, a site built using this approach likely will not be secure against man-in-the-middle attacks, due to the amount of other stuff that isn't protected by a HMAC, and thus won't be safe to use on an open Wifi network. For this reason, I suggest you just use SSL across the board and simplify your life, rather than trying to invent your own cryptographic request authentication format.

Security against password guessing. You'll note that none of my proposed approaches involve generating the cryptographic key as a function of the user's password. Users typically choose passwords. You should expect this will be especially true on mobile platforms, where entering passwords is a pain. For that reason, cryptographic keys derived from passwords will generally provide weak security and can often be broken by dictionary search. For instance, an eavesdropper who captures any one request will be able to mount a brute-force password search attack to recover the password and thus the crypto key, if the crypto key is derived from the password.

While PBKDF2 is an attempt to mitigate this as best as possible, the fundamental vulnerability remains. For this reason, I believe it is better to avoid using cryptographic keys that are derived from passwords, whereever possible. My solutions above are more robust in the face of weak user passwords, because they do not involve sending a password or anything derived as a function of the password in the clear over any connection.

The third-party design. You mention you hired a third party to come up with a design, and they proposed using something like MD5(secrets + data + more data). This is a bad idea. Don't do it. It has multiple cryptographic flaws. First, MD5(secret + data) is a poor message authentication code; it is susceptible to message extension attacks. Second, combining different kinds of data by concatenation is a bad idea and one of the top-ten most common crypto mistakes; both Amazon and Flickr had high-profile security flaws due to this. Instead, I recommend that you use a proper message authentication code (like HMAC), and that you use proper methods for concatenating the data fields that you want to authenticate, e.g., by including length fields.

Answer 2

I working also on a webservice sessionless authentication. Check also amazon s3 auth.

They also do HMAC_SHA256 to "sign" the request with a timestamp.

But it's no strong over http (non ssl) because someone could sniff your request.

Amazon works agains that by only allow request with timestamp within +/- 15 min of the amazon server time.

Of course they also recommend to connect over http*s*.

Answer 3

Even if you here to use this system, you still need to use SSL.

Efficiency is really important for web services and your proposed authentication method is far from efficient or secure. The use of PBKDF2 would be a very poor choice because it would add significant CPU usage for each request and this would add significant lag as this check would have to be made before fulfilling the request.

The use of an HMAC introduces the possibility of an attack. md5 and sha1 both very broken primitives and should never be used in the context of security. (Although it should be noted that hash collisions do not affect HMACs, however hash functions have other problems). Even sha256+PBKDF2 can be cracked on a GPU or FPGA to retrieve your secret which makes this a very poor choice.

You should only use cryptography when there is no other option, you should never use it to introduce flaws into your system, and that is exactly what you are doing with this design. Another example of this flawed approach to session management is the .net oracle padding attack. Encrypting the session information doesn't guarantee that a user can't modify it.

If you want a secure system issue the client a cryptographic nonce. To do this I like using an entropy store like /dev/random. Then use this to retrieve information from a fast datastore like memcachd. Verification doesn't require an expensive hash function. This reduces the bandwidth overhead for each request compared to using an HMAC, and it cannot be tampered because there isn't a cryptographic primitive to break.

Answer 4

As others have said, it is not necessary to implement PBKDF2 on the client side if you are using SSL, but you may want to look into something like CHAP as a lighter-weight supplement to SSL and to address some of the potential vulnerabilities of SSL.

And by the way I think it is a great approach to first come up with how to overdo it, then work back to the more reasonable solution.