Custom EC2-style user authentication system - how secure is it?

Question

At work I'm trying to design a user authentication system that is session-less (including session based tokens such as those used in OAuth2) due to client software requirements. The services are REST and we are trying to design an authentication system that can use HTTP headers to communicate authentication data to the server.

I've used Amazon EC2's request-signing auth [1] before and found it well suited to our requirements, except in our case we will be dealing with individual users (who will have a password) rather than scheduled scripts / automatic systems used to connect to EC2. The system I have come up with works exactly the same as EC2, with one difference: instead of the user's client storing a private API key (the AWS access key described in EC2's docs), they will store a password (per software run) that will then be hashed as it is on the server and used to sign the request.

To summarise how requests will work:

1. User enters password in client software
2. Software one-way hashes (whirlpool) password
3. Software creates a digest (HMAC) of the request using the hashed password
4. Software makes web service call to server, signing it with the digest
5. Repeat step 4 until software exit

On the server:

1. Server receives request, fetches hashed password from user table
2. Server creates digest of request with hashed password and verifies it matches
3. If verified, user is authenticated and request is performed

We will also consider lifetime restricting requests to prevent repeat attacks against the server and preserve idempotence of the service, and using HTTPS where possible to provide an additional security layer (this may not always be possible however, due to software restrictions).

Is this system secure?

[1] http://docs.amazonwebservices.com/AWSEC2/latest/UserGuide/using-query-api.html#query-authentication

Answer 1

First of all you should not use whirlpool, instead you should use NIST Approved Hash function such as SHA-256 or another member of the SHA-2 family. SHA-1, MD4 and MD5 would be poor choices.

The password and the password hash must never be sent over the wire in plain text.

Your current protocol implementation is vulnerable to a Replay Attack. Although an adversary sniffing the wire cannot modify the request unless he knows the password hash or the password, he can still replay any request set. There are number of countermeasures. One is to send a timestamp with every HMAC'ed request. You don't really need to know the client's exact time, just enforce that a timestamp is never repeated or less than the request before it.