facebookarchive / delegatedrecoveryspecification

Allows an application to delegate the capability to recover an account to an account controlled by the same user or entity at a third party service provider.

Delegated Recovery

delegated-account-recovery is a protocol that allows an application to delegate the capability to recover an account (e.g. in the event of a credential loss or compromise) to an account controlled by the same user at a third party service provider.

Usage

This is a specification.

Open Source SDKs and example applications implementing this specification can be found for Java and JavaScript at https://github.com/facebook/DelegatedRecoveryReferenceImplementation, and for Ruby (developed by GitHub) at https://github.com/github/darrrr.

Facebook offers an implementation of the Recovery Provider portion of this protocol, currently in closed beta. Find more information at: https://developers.facebook.com/docs/delegated-recovery/.

Dependencies

The source of the specification is in the xml format used by, and the html generated with xml2rfc

Join the community

See the CONTRIBUTING file for how to help out.

License

The specification is provided under the Creative Commons Attribution 4.0 International license.

delegatedrecoveryspecification's Issues

Create GitHub Page for easy access to documentation

You know, github.io and stuff.

Right now directly from browser we can only look at raw HTML...

Public Keys - Suggested limit of two

It is recommended that up to two public keys should be published in the configuration endpoint, for the sole purpose of key rotation: "The Recovery Provider should not publish more than two keys; enabling key rotation with a small overlap period is the primary purpose of allowing more than one key to be published."
(https://github.com/facebookincubator/DelegatedRecovery/blob/master/draft-hill-delegated-recovery.raw.txt#L631-L640)

I would propose that this limit is removed, for the purpose of high availability.

Consider a scenario where you have a single recovery provider server. At any given time, the server might keep track of a single active key pair and rotate this periodically. After rotation, the old public key should also be kept and published for a short period of time to cover any in-flight recoveries.

Now consider a scenario where you have two (Or more) load-balanced recovery provider servers (Without session affinity) with a shared database of some sorts. With the above limit, the servers would need to share the active primary key and coordinate key rotations.

For security purposes, it might be preferable for each server to have its own private key to prevent the keys from needing to be distributed between the servers. This also simplifies key rotation as each server would be responsible for its own key pair. With this strategy, only the public keys need to be distributed between the servers for the configuration endpoint. This would require up to two keys per server to be published on the configuration endpoint at any given time.

Setup publicly hosted version

I think the .html file should be available online with the right content-type header for easy reading. GitHub's raw feature only serves it as text/plain. Maybe setup GitHub Pages?

Example

https://cdn.rawgit.com/facebookincubator/DelegatedRecovery/d147414e397a8c456ec512588e4e7361db84f913/draft-hill-delegated-recovery.html

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

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.

Recovery token lifecycle

From the text in section 1.3 (https://github.com/facebookincubator/DelegatedRecovery/blob/master/draft-hill-delegated-recovery.raw.txt#L291-L298), it seems that recovery tokens are intended to never expire do not need to be single use. This is acceptable because it is the counter-signature of the recovery provider which provides the authorisation to perform a recovery, not the token itself. This also implies that after a successful recovery, no additional steps need to be performed in order to re-establish the recovery capability.

From a protocol point of view, this all makes sense and seems secure. From a documentation point of view however, this behaviour is only mentioned in passing in section 1.3 - It might be useful to have a section dedicated to explaining these behaviours and nuances.

Only 1 Recovery Provider is bad idea: Own One - Own Them All!

(filing as issue, as mail to [email protected] send on 2017-01-30 went unanswered, maybe sorted to spam or just overlooked? :) )

Parisa Tabriz just posted:
https://twitter.com/laparisa/status/826127516913922048

thus.... quickly going through your draft (0ef7d8f):

https://github.com/facebookincubator/DelegatedRecovery/blob/master/draft-hill-delegated-recovery.raw.txt

It seems you only require 1 recovery provider.

Hence compromising that provider gives one the token and thus full
control over the original account. That is a bad idea....

I think it would be very very wise to have a minimum of 2 or
user-configurable tokens that are required before one can reset the account.

Thus, for my account I register RecProvOrange, RecProvRed, RecProvBlue.

All three have to send a valid token and those combined, before the recovery starts.

If only one comes with a token, that would not trigger the recovery, as
it could just mean that somebody has taken control of that provider.

In a way, that is akin to registering multiple email accounts with
OrgAccount, triggering the recovery and letting them send an email to
each with email address with part of a token, then having to enter that
token at OrgAccount.

The latter is what we do for https://trident.li with the addition that
one of the email addresses is a trusted person ('nominator') who is
vouched to be trust worthy by other people; and of course, we PGP those
emails ;)

That said... I would happily implement a 2+ Recovery Provider scheme for
Trident as that sounds like something that is reasonably secure (as an adversary has to compromise 2+ providers).

And effectively it is an opt-in kind of mechanism as one does have to
register the tokens. Thus from a UI perspective having a "I want these
providers" select click, go to provider site, click would be a good user experience...

Greets,
Jeroen