'Hawk authentication failed' responses to the client are hard to debug about hawkrest

[edmorley]

The exception types present in mohawk are:
InvalidCredentials -> Malformed config on the server side.
CredentialsLookupError -> The "id" doesn't exist in the dict of credentials that the server has.
BadHeaderValue -> The client sent a header that couldn't be parsed.
MacMismatch -> The locally calculated MAC did not match the MAC that was sent.
MisComputedContentHash -> The signature of the content did not match the actual content.
TokenExpired -> The timestamp on a message received has expired.
AlreadyProcessed -> The nonce has already been seen.

For an attacker, knowing that their timestamp is wrong, or payload is malformed doesn't give them anything, since well they created the payload. Similarly, if the server is misconfigured, knowing the exception name was InvalidCredentials gives them nothing.

This leaves:
CredentialsLookupError
MacMismatch
MisComputedContentHash
AlreadyProcessed

So an attacker could try and enumerate valid client ids, or know whether they failed on general MAC / content MAC or nonce, but I'm not sure if that really gives them anything?

We can either:

1. Always output the exception name
2. Output the real exception name in the other cases, but give all four of the above a generic error string?

Do you have a preference? (I'm happy to open a PR for this if it would help)

[kumar303]

Hmm, I am hesitant to add the exception class to the client response. I think it could give the attacker a lot of clues for how the server is configured. I think #15 is a better solution because logging should give you all the clues you need.

[edmorley]

I'm not sure I follow? The server response already gives the user the clue that it's using hawk-rest, that doesn't change (if that's what you meant by "how the server is configured"). In addition, any API docs for a site will have to cover the type of auth being used - ie Hawk. Even if that was somehow secret, security by obscurity adds little value.

I think at the very least we should special-case the TokenExpired case - since that can specifically tell the client that their clock is out of sync.

[edmorley]

The critical thing here is that a client shouldn't have to contact the server operator, the server operator then increase logging level temporarily, ask the client to try again, then the server operator dig through logs and report the error back to the client -- all just for the client to find out the clocks on their automation nodes were more than 60s out of sync :-)

[edmorley]

@hueniverse, as the owner of the upstream Hawk JS implementation, would you mind helping us understand the implications of revealing the exception names above? Many thanks :-)

[kumar303]

Oh, I see, out of sync timestamps is another issue. Yes, we need to deliver that info to the client. I thought there was a bug on file for this but I don't see one. We need a patch to Hawkrest that exposes the signed timestamp from mohawk as explained here.

The node client will recognize this header and calculate an offset (I think?). If it does, that would be a good way to test it out when adding this feature. The mohawk client does not calculate an offset when it sees this kind of header. It should though. It just fails, which is a bug.

[edmorley]

Oh, I see, out of sync timestamps is another issue.

Yeah I agree that the auto-negotiation of a revised timestamp would be a good feature to add to hawk-rest/mohawk (seeing as the JS Hawk implementation supports it), and I'll file issues for it now, but it's not what I meant by:

all just for the client to find out the clocks on their automation nodes were more than 60s out of sync

Just having the information be returned in the response to the client, so a human can read the logs and fix NTP on their machine would be useful in the meantime.

It feels like maybe you've missed this alternative suggestion from above:

2. Output the real exception name in the other cases, but give all four of the above a generic error string?

ie: Even if some of the exception types names give away too much information, there are still some that are both:
(a) Very useful for the client to know in the response, since it can help them realise they are making a genuine mistake.
(b) Safe to reveal, since it's not directly related to the authentication.

At the least, these two appear to meet those criteria:

• TokenExpired -> Would let the developer who is operating the client see in their own logs that they need to fix NTP on their machines. Ideally hawk-rest and the client would self-negotiate as you mention above, but that's a more complex fix and not all clients have support. Telling the user that the token has expired isn't revealing anything more than this self-negotiating feature would do, when it was implemented in the future.
• BadHeaderValue -> This would let the developer who is operating the client see that the client has sent a malformed header. A malicious client already knows the content of what it is sending, so won't gain anything useful by knowing it's un-parsable, but a well-meaning-but-broken client would gain a lot from knowing there was a bug.

Presuming that sounds ok, I'll open a PR - if only since it will make the proposal clearer :-)

[kumar303]

ok, sure, exposing TokenExpired and BadHeaderValue seems safe enough. I think the others are unsafe, especially credentials lookup because that could be used to brute force accounts if they had partial account info.

I think instead of something like Hawk authentication failed: BadHeaderValue it would be nice to say it in plain English like Hawk authentication failed: the request header was malformed.

[kumar303]

btw, I think what you're experiencing is best solved using an NTP server. The Hawk spec calls for this too but mohawk needs better support around this. I filed this to track it: kumar303/mohawk#12

[hueniverse]

In general, you want to give as little as possible to an attacker trying to get into your system. But use common sense and decide which error is ok to share.