4 ms·

If you want to support communication over non-secure connections, you'd want to provide a "secret" key, and an ID for that key. Then you'd create an HMAC hash w

If you want to support communication over non-secure connections, you'd want to provide a "secret" key, and an ID for that key. Then you'd create an HMAC hash with the secret key, rather than actually sending the key. Doing that securely and protecting against replay attacks is non-trivial though.

jessaustin 10y ago
This seems like something we're not supposed to do... why not just use tls or ssh?
- vertex-four 10y ago
  TLS client authentication (which I think is what you're getting at) is a pain in the ass to implement clients for properly - OpenSSL is dreadful to use, and for many HTTP client libraries you'll need to use it (or a very thin wrapper) to set X.509 client certs, if you even can. On the other hand, there's decent libraries and plenty of information on how to generate and verify an HMAC, and avoid replay attacks.
  - jessaustin 10y ago
    No that's not what I'm getting at. I'm saying the design of secure protocols is best left for smart people. Every time you post on HN, you're using cookie auth, but you don't have to worry about replay attacks because everything runs inside TLS. Any environment that has HMAC libraries also has the libraries one would need to do the right thing.
    - nitrogen 10y ago
      HMAC is useful for expiring, limited-use tokens without having to store every single token, just the base key. It's used by CloudFront, for example.
      - jessaustin 10y ago
        Oh definitely, just pointing out that TLS client certs are used only rarely.
- pjscott 10y ago
  As far as I can tell, that's the usual way to do it these days: make the API HTTPS-only, and stick the auth token in each request. Using secure connections isn't expensive anymore.
- BillinghamJ 10y ago
  Indeed, hence my comment about it being non-trivial. Regardless, there are many possible cases where you wouldn't be able to use TLS for whatever reason, though it's very rare.
zackelan 10y ago
For an example of just how non-trivial this is, take a look at the version history of how AWS requires signing API requests. Version 1 had a serious flaw [0] related to how the string to be HMAC'd was constructed. It used an appropriate and well-studied cryptographic building block (HMAC-SHA1) and is an excellent case study in why using the right building blocks isn't sufficient to have a secure protocol. Version 2 fixed the issues with version 1, but it in turn has been superseded by v4 [1] (no idea what happened to v3). A v4 signature uses a derived key for the HMAC, and included in the derivation is the current date as well as the AWS region you're making the call to. Beyond time-based replay attacks, this also prevents an attacker from capturing a valid request to eg US-EAST-1 and replaying that request in a different AWS region. 0: http://www.daemonology.net/blog/2008-12-18-AWS-signature-version-1-is-insecure.html http://www.daemonology.net/blog/2008-12-18-AWS-signature-ver... 1: https://docs.aws.amazon.com/general/latest/gr/sigv4_changes.html https://docs.aws.amazon.com/general/latest/gr/sigv4_changes....

jessaustin 10y ago

This seems like something we're not supposed to do... why not just use tls or ssh?

vertex-four 10y ago
TLS client authentication (which I think is what you're getting at) is a pain in the ass to implement clients for properly - OpenSSL is dreadful to use, and for many HTTP client libraries you'll need to use it (or a very thin wrapper) to set X.509 client certs, if you even can. On the other hand, there's decent libraries and plenty of information on how to generate and verify an HMAC, and avoid replay attacks.
- jessaustin 10y ago
  No that's not what I'm getting at. I'm saying the design of secure protocols is best left for smart people. Every time you post on HN, you're using cookie auth, but you don't have to worry about replay attacks because everything runs inside TLS. Any environment that has HMAC libraries also has the libraries one would need to do the right thing.
  - nitrogen 10y ago
    HMAC is useful for expiring, limited-use tokens without having to store every single token, just the base key. It's used by CloudFront, for example.
    - jessaustin 10y ago
      Oh definitely, just pointing out that TLS client certs are used only rarely.
pjscott 10y ago
As far as I can tell, that's the usual way to do it these days: make the API HTTPS-only, and stick the auth token in each request. Using secure connections isn't expensive anymore.
BillinghamJ 10y ago
Indeed, hence my comment about it being non-trivial. Regardless, there are many possible cases where you wouldn't be able to use TLS for whatever reason, though it's very rare.

zackelan 10y ago

For an example of just how non-trivial this is, take a look at the version history of how AWS requires signing API requests. Version 1 had a serious flaw [0] related to how the string to be HMAC'd was constructed. It used an appropriate and well-studied cryptographic building block (HMAC-SHA1) and is an excellent case study in why using the right building blocks isn't sufficient to have a secure protocol. Version 2 fixed the issues with version 1, but it in turn has been superseded by v4 [1] (no idea what happened to v3). A v4 signature uses a derived key for the HMAC, and included in the derivation is the current date as well as the AWS region you're making the call to. Beyond time-based replay attacks, this also prevents an attacker from capturing a valid request to eg US-EAST-1 and replaying that request in a different AWS region. 0: http://www.daemonology.net/blog/2008-12-18-AWS-signature-version-1-is-insecure.html http://www.daemonology.net/blog/2008-12-18-AWS-signature-ver... 1: https://docs.aws.amazon.com/general/latest/gr/sigv4_changes.html https://docs.aws.amazon.com/general/latest/gr/sigv4_changes....