Otdfbt

I work for a small company, developing an ASP.NET web-application. Recently, we've had the requirement of exposing an API endpoint come up, such that an automated script running in the cloud can periodically pull back some specific JSON-formatted data from the app via a web request. The implementation of this I can handle, but I wasn't sure regarding security concerns. I was reading about HMAC this morning & liked the look of it, as it seemed quite similar to the security protocols of other APIs I've used previously. However, it made me wonder what the value of some of the steps were.

If a client and server have securely agreed on a passphrase / key via prior communication, what risk is there in sending a POST request with the passphrase as part of the body of the HTTPS request, such that the passphrase identifies the user? Trying to look this up I came across Replay Attacks and similar, but can these work over SSL & given the client-side & server-side environments can both be trusted?

Edit: Adding a bit of clarification based on a user's comment below. Our intended use case is to have a script run periodically (once an hour, day, etc) either on one of our servers or in the cloud. It will pull back specific information from our app, as well as third-party APIs, & update a cloud-based spreadsheet for our business development team. It's something we ideally want to leave running & not require any user intervention. Our app normally requires login with a username/password to generate a temporary session, but we were hoping to simplify the process a bit & just provide an API for the script to securely retrieve specific data.

Assuming you mean TLS instead of genuine SSL (which is far older and broken), it is absolutely fine to transmit the password in a POST request. This is standard and how virtually every major and secure web authentication service works. You just have to make sure that the TLS is configured properly. TLS mitigates all the attacks you are worried about. It uses HMAC (or a similar authentication) for integrity, and mitigates replay attacks, reflection attacks, and similar issues that affect authentication systems.

HTTPS serves a few purposes, preventing replay attacks and providing confidentiality of the message being sent. To uphold these guarantees, the client must of course verify the TLS certificate from the server correctly, i.e. match certificate against the expected domain (or if you have self-signed certificates, against a fingerprint). Otherwise, a man-in-the-middle attack can take place without either end noticing. This way, the client knows it is really talking to the right server.

But how can the server trust the client? For that, you could use either a client certificate or, as you propose, an API key. API keys are a common concept so if there was some big issue with doing this, we would have stopped doing it by now. It is good practice to regularly renew an API key and it might convenient to have a key ID field to be able to rotate them easily, but generally it should not be a big risk to use the same key for years -- of course, it depends on the sensitivity of the information, how many people have access to the key, etc.

I disagree on the safety of sending shared secrets over HTTPS.

Here's my reasoning :

SSL/TLS was intended to keep someone from being able to compromise the conversation as it happens. As such, there exist webservers installed with weak ciphers. (Not everyone can keep their OS up-to-date; some of us still have to support outdated hardware that may not be able to be updated)

With a weak cipher, or with some of the flaws that @amcgregor listed, someone might be able to view the message minutes after they were sent, which is the reason why they're suggesting that you use the timestamp to hash the authentication token.

If you're sending the shared secret with every message, then an attacker need only see any one of the incoming messages to permanently undo your security. (at least, until that password is changed, which let's face it, isn't going to happen unless they do something to alert you to it)

If you're using more secure means (a challenge/response to assign a time-limited token), then the snooping party needs to view two specific messages (the challenge and response), and use that to get candidates for the shared secret, and then either get more challenge/response keys to narrow it down, or start trying all of the candidates and give you a sign of their attack.

Putting your shared secret on the wire, no matter how good the encryption, means that you're relying on a single layer of security, and in practice that is a bad idea.