Only 1 Recovery Provider is bad idea: Own One - Own Them All!
Closed this issue · 10 comments
(filing as issue, as mail to hillbrad@fb.com 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):
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
Hi, Jeroen. Thank you for the feedback.
The protocol doesn't require anything in this regard, it only describes the standardized flows to coordinate between two services and a person with accounts at each service. It is outside the scope of the protocol to describe whether a single delegated recovery ceremony is adequate for the needs of a given account provider, or what other evidence they may require.
It will, I hope, enable services to build two-factor or m-of-n recovery mechanisms as you describe, by breaking the necessity to use an email, phone number or any other specific type of account identifier, so that a wider variety of services where people have trusted accounts can provide evidence of continuity of identity.
Perhaps the best demonstration that this is already possible with this protocol, as-is, is that the initial deployment by GitHub uses it as a second factor in addition to email, SMS and a customer service contact.
People use a wide variety of services across the Internet with varying needs for trust and convenience. We feel that it is best to leave the decisions about what constitutes adequate evidence to recover an account to the discretion of the services where those accounts reside, while offering tools to make it as secure and easy to use as possible.
Correct me if I am totally wrong but:
- Eve hacks/works-for Facebook.
- Eve triggers a account reset for the Github Account of Alice
- Eve gets new account details for Alice's Github account
There is no stop there, everything is sourced from the user who can operate the Facebook account.
Hence, I heavily suggest that a minimum of two recovery providers is required to be sufficient for the protocol to succeed. Indeed, that is "simply" done by running the protocol multiple times.
This should be HEAVILY highlighted in the Security Considerations section. Noting that there is some wording there that is similar but one will not read this when reading the spec.
Now, of course the astute reader will have read the above "works-for Facebook" thing, and that is the worrying part of it all: Anybody working-for or hacking Facebook (or any other single provider) gets control over all the accounts that user has. Yes, the user will get an email (but they just took over the Gmail account too). Which would be a lot of fun for Github when the user has a lot of high profile projects, but even worse when people start using this for banks and other things.
Facebook is doing a lot of good things, please keep that coming by defining this protocol properly: require multiple reset providers.
Googling a bit, I am not the only one who has raised this concern:
Eric Lawrence I think I'm probably missing something obvious here, but doesn't this degenerate into "Compromise one account the user holds and you've compromised them all"?
Like · Reply · 5 · January 31 at 6:35pm
and:
Luka Perčič Hi Brad Hill, this solution is not trustless- you are making yourself (facebook) and other Recovery Providers target for hackers and secret court orders. That means people would have to add multiple providers to protect themselves enough (2fa recovery provider?!), which makes the whole procedure not easy to use and hardly worth deployment/education hassle.
Like · Reply · February 5 at 4:34pm · Edited
As you seem to have been able to close the issue in 11 minutes, without answering my email from Jan 30, or the above two emails. What gives?
If one delegated recovery become very popular (and that is very likely Facebook) , then that provider essentially controls a large amount of Internet accounts from various websites. Are we giving too much power to one company? Also how the delegated provider complies court order if they have direct control over external account?
Today, the methods in wide use for account recovery are emailed links, security questions, and codes sent by SMS. If you can demonstrate that delegated account recovery is less secure than these methods, that is an interesting issue to address. I don't believe that is the case. It is more secure by default, especially for the types of risks discussed in this issue, and it allows building systems that require multiple trusted parties more easily than those other solutions.
A protocol specification cannot mandate which or how many third parties an implementer must trust. That is a decision for the implementer, to be made in concert with their users.
Facebook has open sourced the protocol and implementations in order to encourage the development of a diverse ecosystem of recovery providers so that people will have robust choices available about who they choose to trust and, when circumstances merit, to be able to rely on attestations from multiple trusted parties.
If you want everyone to have other options available, deploying an independent recovery provider service or building an open and self-hostable application that acts as a user-controlled recovery provider are my suggestions.
If you can demonstrate that delegated account recovery is less secure than these methods, that is an interesting issue to address.
Easy: One employee of Facebook who does not like Facebook too much anymore or is on their way out for doing something bad or anybody else who (il)legally get access to be able to initiate the reset. (And do replace Facebook with "recovery provider", not picking on a company that does pretty amazingly well in the security department :) )
Extreme Examples: NSA because of Snowden and all the followup folks, and now Shadowbroker etc even those places get their data dumped, which means they had nefarious access at one point and thus could also trigger these kind of things.
But even simpler: if somebody gets to guess the password Tinkerbell for a "famous" lady, suddenly they have access to the other accounts that are listed there to. RATs are everywhere (heck, I even got tricked into one one day.... as a friend had one installed on her computer.... and voila, my account popped, grmbl).
Trusting a single entity is never a good idea. Two is at least a bit better.
Having a human (as Facebook has with the 'trusted person for reset' scheme) is already a bit better even.
Hence, why I am asking that:
- the spec states that at minimum two other parties are involved.
- implementations are verified to follow that.
If implementations do not (very little one can do about it), then it is at least not the fault of the spec when such a hole gets used...
Every one of these scenarios is worse with email and SMS based recovery using plaintext messages with a single trusted email provider or carrier.
Every one of these scenarios is worse with email and SMS based recovery using plaintext messages with a single trusted email provider or carrier.
The SINGLE provider is the key there.
If you had multiple providers, one would have to compromise multiple providers.
Same thing why we call it SECOND factor Authentication. Because one needs to compromise multiple factors (providers of authentication) to get to the goodies.
Does that better explain the problem I am trying to get at?
Even the protocol couldn't mandate how many providers the SP should trust, could the protocol outline the procedure for multiple providers? E.g. redirecting from a provider to another provider after a successful key retrieve?
Even the protocol couldn't mandate how many providers the SP should trust, could the protocol outline the procedure for multiple providers? E.g. redirecting from a provider to another provider after a successful key retrieve?
It should not do that, as that might disclose information to one provider that the other exists. While only the real service needs to know that.
Just doing multiple iterations is fine, nothing complex needed thre, but it has to be multiple iterations (2 at minimum....)