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  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:
- User enters password in client software
- Software one-way hashes (whirlpool) password
- Software creates a digest (HMAC) of the request using the hashed password
- Software makes web service call to server, signing it with the digest
- Repeat step 4 until software exit
On the server:
- Server receives request, fetches hashed password from user table
- Server creates digest of request with hashed password and verifies it matches
- 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?