HMAC Authentication: Better protection for your API

Pim Brouwers on September 11, 2018

Building web software today is all about API's (application programming interface's). Whether your implementing your own microservice architectur... [Read Full]
markdown guide
 

HMAC is one more security layer in your API defence but when used from a Mobile App to talk with an API it can be defeated as explained on this article.

Despite HMAC can be defeated is better to use it with the JWT token than using only an API key or basic authentication.

For more techniques in defending your API please check this series of articles written by some of my colleagues at work.

 

Without reading the article, I have to say that I'm skeptical basic authentication is somehow more secure then HMAC. But I am not an expert in matters of security. I will add the referenced article to my reading list. Thanks for the share!

 

Sorry but I have not said that basic authentication is better than HMAC I was trying to say that despite HMAC can be defeated is better to use HMAC than basic authentication... I will edit my reply to make it clear.

I am glad you pointed it because after I read it again I have to admit that was confusing.

Thanks

 

Just a small correction. Basic authentication doesn't utilize 'digest' term as it mixes with Digest from the Digest authentication.

base64(username:password) is not a 'digest', but just encoded credentials. Neither encoded value is 'hash'. Hash is a one-way cryptographical operation whereas base64 can be decoded back.
Digest is a collection of several additional properties like nonce, cnonce, URI, etc.

Further on. Adding just a timestamp doesn't help security much as the attacker has this info as well (to some extent, which decreases the amount of tries he would need to generate a correct hash)

 

Hello Pim,

Thanks for sharing, but what about the server side code to verify the validity of the hash? could you provide an example ?

Thanks

 

Thanks for the feedback. This is pretty instance specific, but is the reason the username is included un-encoded. You would use this value to lookup the user (perhaps in a database), if there's a matching record build the hash internally and compare to what's provided.

 

Umm.. please don't store passwords on the server. You'd need to devise a way of storing something irreversibly derived from the true password that the client also does to the password and uses that as the hmac key.

 

Absolutely not. This is for demonstration purposes only. Passwords must be encrypted before any persistence happens. I typically use PBKDF2.

 

Awesome article on hmac. You really nailed the reasons people should use it. I'll also add you can use JWT tokens to offer control over more things like TTL.

 

Thank you so much for the feedback. JWT's are certainly a solid alternative!

code of conduct - report abuse