facebookarchive/DelegatedRecoverySpecification

Rewriting as a description of how Macaroons can solve the same problem, with fewer round trips and a simpler protocol

Closed this issue · 2 comments

WildCryptoFox commented

Rewriting as a description of how Macaroons can solve the same problem, with fewer round trips and a simpler protocol

In the meantime, please see the source material as linked.

hillbrad commented

Hi, @james-darkfox, I'm aware of Macaroons. I don't believe they meet the use cases and deployment strategies this project aims to achieve.

WildCryptoFox commented

@hillbrad Sorry I haven't had the time to rewrite this issue. If you believe that is the case, I suggest re-reading over the macaroons paper.

Specifically a third party which provides an encrypt and decrypt function, unique to the user, is all that is necessary. The third party stores nothing; unlike the primary service (that we're trying to recover), which stores (and serves) a partial-macaroon.

The partial macaroon contains an encrypted tag, while the third party may decrypt the tag and add additional caveats. The third party never gains any authority over the account. No signatures are required, just MACs. The primary service does not need to know who the third party is, nor do they need to communicate.

Likewise the in DR, the primary service encrypts and authenticates* secret** information, then signs it*; entrusts a third party to store and eventually sign*** the blob.

* authenticated twice, symmetrically and asymmetrically; where the latter is useless unless the third party verifies it before storing (minimal to no advantage)

** non-forward secret

*** the third party can sign and redeem the recovery without the user (at least this is intended as a second factor to recovery)

To reiterate: macaroons do not impose any storage to the third party (TP provides user-specific functions), while the primary service may store (or forget) any number of valid partial-macaroons. Neither party needs to learn anything about the other.

  • User asks PS for partial-macaroon.
  • User already authenticated to TP, asks it to decrypt the tag.
  • TP decrypts the tag, and optionally adds additional caveats; sending this to the user.
  • User uses the complete macaroon to authenticate the account recovery request.

I may have specific details incorrect; however the general concept has been solved by Macaroons -- not me.