Hello, Le Sat, 16 Apr 2016 11:30:39 +0200 "sheel.at" <[email protected]> a écrit:
> Suppose an account key gets compromised. To prevent abuse, the owner > can delete the account: > https://github.com/ietf-wg-acme/acme/blob/master/draft-ietf-acme-acme.md#deleting-an-account > However, people having the key can simply change it without any > effort: > https://github.com/ietf-wg-acme/acme/blob/master/draft-ietf-acme-acme.md#account-key-roll-over > > What happens if the attacker does so before the owner can react, or > even before the owner notices anything of the breach? > > I suggest changing tha specs (and implementation) to keep old keys > after changes for while. More specifically: > * When an account key is rolled over, the old key is kept for eg. 30 > days. > * Multiple changes within this 30 days mean that there are multiple > old keys. > * Account deletion is possible with any of the saved keys, be it old > or new. > * Everything else (other than account deletion) only accepts the new > (newest) key. In the spec above, apparently nothing prevents the attacker from rolling over and over again, and the server will only be able to handle a finite number of keys before it either misfunctions or decides to drop the newest or oldest keys. I might have missed something, but it seems to me that we thus might have the following scenarios: - server cannot handle more than N rollovers: that is a (D)DoS opportunity for the attacker, not against the victim user, but against the server. - server handles more than N rollovers by not accepting more than N (dropping the newest keys): attacker can still lock out the victim by doing N rollovers before the victim does their first (and we can safely assume the victim won't realize there is an attack immediately). - server handles more than N rollovers by only keeping the last N keys (dropping the oldest keys): again, the attacker can force N rollovers so that the victim's key "drops out" as the oldest, and the victim is then locked out. Again, maybe these scenarios cannot really happen due to some part of the specification which I missed. And if they can, then no, I don't see any simple solution, at least not off the top of my head. Amicalement, -- Albert. _______________________________________________ Acme mailing list [email protected] https://www.ietf.org/mailman/listinfo/acme
