

Ask HN: HMAC Authentication? - exabrial

Hey guys,<p>Writing an API here. In the past for authentication,  I&#x27;ve had people include an Authorization: token token=blah in the header.<p>Since SSL might not be an option for some of our customers (yes, sigh), and to guard against replay attacks, we need to encode the token somehow.<p>I noticed amazon uses HMAC, so I set out to create something similar. No, I&#x27;m not trying to make my own crypto, I&#x27;m trying to use the cryptographic primitives as they were intended:<p>Authorization: hmac_v0
 time=urlEncode(iso8601(currentTimeStamp())),
 username=urlEncode(username()),
 nonce=urlEncode(base64(random(15))),
 sig=urlEncode(base64(HMAC(&quot;SHA-512&quot;, base64^-1(secretKey()), bytes(time+&quot;:&quot;+username()+&quot;:&quot;+nonce))))<p>Thoughts welcome!
======
tptacek
Amazon uses HMAC authentication because their API supports delegation: the
owner of an API resource can craft HTTP URLs that non-owners can use to access
the resource in limited ways.

Amazon's API thus needs the ability to create links with built-in integrity
checks.

But that feature is a complication. If you don't need it, you should avoid it
(for almost all APIs, YAGNI).

Furthermore, if you pay close attention to Amazon's own APIs, you'll see that
they got bit for doing this: the canonicalization step they used to make
semantically equivalent URLs share the same MAC was vulnerable to an attack
that they later had to fix.

Using a library HMAC helps you here; at least you're not doing what Flickr
did, and crafting your own hash MAC that Thai Duong will later document to be
terribly vulnerable. But you still need to make sure that your HMAC library
isn't timeable, and you'll also need to make sure that there aren't type
confusion bugs that will make invalid HMACs compare true (I don't know what
language you're using).

I'd avoid this altogether and just issue 128+-bit API secrets, like most APIs
do.

