Facebook PGP Authentication

[zQueal]

I opened a new issue to keep discussion out of #518 for the sanity of those who subscribed to the issue.

---

[Original Discussion]

I just tested this process;

Once you enter your public key, Facebook generates an encrypted email and sends it to you.

This is correct. So to even establish a link between your profile and your public key you have to click an encrypted link held within the message that Facebook sends you -- establishing that you have possession of the private key.

This could be viable if there's a way to programatically check for a user's public key within the graph API, for example. However, at that point you're really trusting that Facebook is doing due diligence--which is not ideal at all. I think there has to be a medium which includes a signed statement somewhere. Perhaps in the profile fields? If that's completed securing Facebook accounts would probably be one of the strongest proofs we have. You have to establish your identity to Facebook (by having the private key) and then using the same key pair, sign a prepared statement for Keybase.

[chigh]

Notes can be set to public, and the proof could be placed in there... e.g. i created a note, made it public and it had a semi-neat URL: https://www.facebook.com/notes/clair-high/test-for-potential-keybase-use/10153410972212432

[pathawks]

Wouldn’t even have to be a note, could just be a regular timeline post, right?

[CodingAnarchy]

Should be able to be either.

[akhepcat]

From a user standpoint, a timeline post is probably "easier" because it's a single click from the newsfeed, whereas getting to the "notes" is quite convoluted anymore.

Also, the URL tends to be shorter on the 'feed.

[CodingAnarchy]

@zQueal, I checked the Facebook graph API, and it does have a field for public_key within the user node. (https://developers.facebook.com/docs/graph-api/reference/user)

Additionally, there is a verified field that is considered true, per the documentation, if the user is either registered for mobile, confirmed via SMS, or associated their credit card with the account. (Don't know whether any of that is relevant to the checking involved here, but thought I'd mention it.)

[ghost]

The problem is that there are two unverified points of failure: Facebook, and the user's email account. First, you need to trust Facebook that the key is actually verified. A malicious admin could post a "verified" key.

Secondly, if someone hacks into the email of a user, and gets into their Facebook account, they could upload their own public key, and the malicious hacker would be able to then decrypt the email and "verify" the key. [Arguably, this is an issue in all services: if someone hacks into your twitter feed they could then post a keybase proof there too. So the entire system is based on trust that the social services themselves have not been compromised.]

[akhepcat]

That's really a straw-man argument, as you point out parenthetically at the end of your post.

Whether facebook, reddit, twitter, or public email, they all have their weaknesses in that the user doesn't control the communications, processing, and data storage end-to-end.

There is no way to prove that a key hasn't been exposed to the world. There is also no way to prove that a "bad actor" hasn't subverted the process.

The point here, is to provide a greater-than-zero probability that the user asserting ownership of a resource is actually the owner.

That's all.

[CodingAnarchy]

I'm in agreement here. If we are operating under the assumption that a social media service is broken into, there's no point to this.

I see no reason to rely on Facebook to verify the key, particularly if the private key is used to sign the message on Keybase's side.

[pathawks]

I see no reason to rely on Facebook to verify the key, particularly if the private key is used to sign the message on Keybase's side.

Now there's an interesting idea.

With most services, the verification is built on Keybase having the public key, and a signed statement being posted to the service verifying that the owner of that profile has access to the public key.

With Facebook, since Facebook already has the public key, maybe a statement signed with that key and posted to Keybase would be enough to prove that the same entity controls both accounts?

[zQueal]

With most services, the verification is built on Keybase having the public key, and a signed statement being posted to the service verifying that the owner of that profile has access to the public key.

IMHO, this is a bit off. Facebook would have strong verification because it would rely on Facebook verifying that the person has access to the private key, and then Keybase verification which would involve posting a signed statement that is publicly verifiable. If you don't trust Facebook, that's fine. You can always check the statement yourself--and if you do happen to trust Facebook, and the way that they validate a person's ownership of a key, then you get an extra layer of validation that we don't have for any other service.

[CodingAnarchy]

What if you have the option of doing either or both? You could rely on Facebook to verify the public key, but we could print out a warning (on CLI; display it on the web) that notifies people that only Facebook's verification process has been done. Or you could do the same way as Twitter, etc. where a public post can verify it directly with a signed message?

[zQueal]

You could rely on Facebook to verify the public key, but we could print out a warning (on CLI; display it on the web) that notifies people that only Facebook's verification process has been done.

If I understand this correctly, there is a very low percentage chance of this happening. All keybase proofs should be public and processed through keybase as a service. This means that if you validate on facebook and just add the "proof" to your profile without posting a public record, there's no real attachment to the keybase system other than a link on your profile. Nothing has really been validated. If anything happens, it would be the same as any other proof and would require a public posting of some form of verification via signed statement and hashes, etc.

[CodingAnarchy]

Which is why I wouldn't consider it a "proof".

I think, however, a "this public key appears to be associated with this Facebook account" notification isn't useless, difficult, or harmful here.

[akhepcat]

So, a 2-level approach?

1) user has posted a PGP key, which Facebook has validated as belonging to the account. (use the facebook API to read the key, which should match the Keybase account's public key)

2) user has publicly submitted a (note/post) containing a validated Keybase statement. (supply the URL back to keybase)

But the question remains: does either of those two options provide "more assurance" than the other?

[oconnor663]

@akhepcat One downside to (1): If I steal a Facebook user's PGP private key, I could create a new Keybase account posing as that user, without actually needing to compromise the Facebook account. With (2) this isn't possible, because the proof includes the account name it belongs to -- you have to control the key and the account to create a fake identity.

Not that we expect you to have much security when people steal your private keys...but anyway it's a difference.

[akhepcat]

@oconnor663 the straw-man is "stealing the PGP private key" which invalidates anything.

But remember, I explicitly said 2-level.

Something like: level one is "yellow" ( key matches, no validated assertions); and level two is "green" (key matches, validated assertion is available)

[carnage]

I think you should just treat Facebook like any other service: require a publicly verifiable proof. It may well be that I decide to use a different public/private key pair for facebook because uploading a keypair to facebook means that all email from facebook will now be encrypted. As I read that email on my phone, which is at a higher risk of compromise than my desktop; A separate key pair may make sense.

Keybase verification shouldn't require the public key I give key base and the one I give facebook to match.

[akhepcat]

@carnage While I can't speak to Keybase's requirements for accounts and keys to match up, there's currently no provision in Keybase for owning multiple pgp keys that I'm aware of.

So your particular case would be completely untrusted, at least from my cursory look.

That said, I would love to see support for multiple keys, or subtended keys, exactly for this reason.

I don't have PGP on my phone, so I don't get to read the facebook notifications or any other PGP-encrypted messages while mobile. I'm not entirely sure I want to deal with key replacement every time I lose my phone, though - which currently is "never" but has been "almost" more than once.

[zQueal]

I think, however, a "this public key appears to be associated with this Facebook account" notification isn't useless, difficult, or harmful here.

Very true.

[danielmcclure]

If you check out the OneName verification system, they require you post a public status for Facebook with a verification message. This seems like a viable way of verifying for Keybase too?

As a sidenote, OneName is probably a great service to build verification for too.

[NoSubstitute]

It's been five months and Keybase still can't verify against the largest social network in the world. Nor against Google+, which sits with an equally enormous userbase, and isn't even listed among the "accepted". Both sites have the ability to post any long unformatted text (or simply formatted, with newline), only editable by the actual user, but neither can force the url beforehand. Though, both will have permantent urls to the post afterwards.

[zQueal]

Everything said, Keybase is going through a refactoring right now. From the old client which was written in Node to a new client which is now written in Go. Additionally, focus from the team also seems to be centered around the Keybase file system which could attract a serious number of new users. Not many services allow you to assert ownership of files via cryptographic proofs.

Other than that, Keybase is open to pulls. If development is progressing too slowly for you, you can always open a pull request!

[NoSubstitute]

I wish I could code, so I could help out for real.

[awakeman]

Still waiting on this feature. Facebook has multiple methods, discussed here already, of posting publically reachable and permanently referencable posts, adding support should be trivial. If i get some time soon I might be able to take a look myself.

[0x4445565A]

In hopes of progressing this issue I started hacking apart the Twitter proof command for the CLI client. I have found a way that doesn't require an APIs and can be viewed publicly. On the Facebook profile there is a section called "Quotes" that can be pulled without doing anything funky.

The quotes section is found in a div with the id #pagelet_quotes

I was hoping to have at least the grabber and proof generator working but I'm running into the issue of this error.. ▶ ERROR Don't recognize signature type: web_service_binding.facebook (error 1001)

So if anyone wants to take my patch and get the proof gen working I would be happy to do the HTML parsing like in the Twitter proof...

1650.patch.txt

[cjb]

@0x4445565A Thanks for looking at it! @oconnor663 is actually working on this right now internally, and we should have something ready to look at soon. :)

[oconnor663]

Yep, good timing!