Why we were surprised (and we don't say the implementation is necessarily wrong!) is that I can use the account key anywhere. If the genuine user keeps refreshing authz's, it will keep the stolen account key operational as well.
That's my understanding. I may be wrong, but if so, I don't quite yet understand the logic behind authz.
Think of it like the credentials for a hosting provider where you bought your traditional SSL certificate being stolen. Not really a new threat.
The authz should be tied to the { domain, account_key } tuple, not just the { domain }.
Can anyone confirm?
I have multiple servers that serve { domain } in dns round-robin. Each of them has a unique account key, but they also each issue certs for the same domain.
This is a totally normal and valid use-case, and allowing only a single account key for a domain at a time would ruin it.
I'm sure this is what was meant, but just to confirm and spell it out, the authorization
has to belong to the subscriber account that's making the request right?
@tialaramex Apologies that it wasn't clear - you are absolutely correct. Authorizations
are only reused within a subscriber account.
tialaramex: If account A asks to create an authz for example.com, succeeds in validating
it, and then account B comes along and wants an authz for example.com too, that should
result in a fresh authz regardless of this setting.
Correct. Account B's request would result in a fresh authz in pending state.
Since, remember, it is trivial for anyone to get a new account_key, there is absolutely no validation that occurs to setup a new account key for a given domain. This is why I don't understand the purpose behind the account_key in the first place.
[1] - https://community.letsencrypt.org/t/upcoming-change-valid-au...
If you aren't authorizing and revoking immediately after delivering data, you're doing it wrong and opening yourself up to attack.
Source: Four penny auction websites using the same code were compromised by me (at their request - hired hacker.) I took their entire auction winnings after they gave me authorization to test their systems. It took me less than 20 minutes.
I walked away with $300,000 because in my contract I told them I keep whatever I compromise and steal. They agreed.
If you can't handle rapid token usage/generation, don't even bother using tokens. Token revocation is one of the harder things out there to get done properly. You're better off with a challenge/auth EVERY SINGLE REQUEST at the expense of page loading times.
I'll try to phrase this as an example: Let's say you run an online store for music downloads. One implementation might be to send the user an email with a download link, identified by a token. In this case, it would make sense for this token to expire after the user successfully downloaded the file, and doing otherwise would probably be bad for your business. On the other hand, if your online store involves a login process you need to complete before you can actually download the file (the file being the domain authorization in this example), that's fine and you might not want to limit the user to one download.