Single Sign On

[davidar]

I'm not sure if this has been brought up before, or if this is even within scope, but it would be great if keybase were able to make it possible to login to websites using my GPG key. I currently use pass to encrypt my (randomly generated) passwords using GPG, but it would make more sense to cut out the password middle-man entirely. For example:

1. go to a website and click "login with keybase"
2. the website connects to keybase (perhaps with something like OpenID or OAuth)
3. keybase forwards the request to either the CLI client or the in-browser client
4. I sign/decrypt an appropriate challenge with my GPG key to verify my identity
5. an appropriate response is sent back to the original website to authenticate

Ideally this could be done without even needing either party to trust keybase.io, but don't ask me how :)

[MuhammedZakir]

ACK. However, I don't think this would be useful for users who imported their PGP private keys. Kindly, Muhammed Zakir

[davidar]

@MuhammedZakir Thanks for the reply. I'm not sure why this would not be useful for those users though, could you elaborate?

[MuhammedZakir]

Most of the users import private key or create a PGP key using Keybase to use Keybase as their client. Some of them use other clients though. Still, it doesn't really make sense for users who use Keybase as their PGP client to sign in with their PGP key. FWIW, I am not saying it should be disabled for accounts with PGP private key. Just saying, it won't be much use to 'em, in fact, I doubt it would be any use to them. However, signing in with PGP key is certainly a great idea. If it is implemented, it will be great to sign in with Bitcoin address too!

[davidar]

Still, it doesn't really make sense for users who use Keybase as their PGP client to sign in with their PGP key.

I disagree. If this were implemented in a way that doesn't require trusting the keybase.io server (client-side crypto, hyperboot-style security CC:@substack, etc) it would be much more difficult for attackers to spoof logins in the event of a server breach, making this a more secure alternative to other SSO providers.

However, signing in with PGP key is certainly a great idea. If it is implemented, it will be great to sign in with Bitcoin address too!

I'll limit this specific issue to PGP support, but I agree that it would be even better to support other kinds of keys too (personally I'd add SSH keys to that list too).

[MuhammedZakir]

I disagree. If this were implemented in a way that doesn't require trusting the keybase.io server (client-side crypto, hyperboot-style security CC:@substack, etc) it would be much more difficult for attackers to spoof logins in the event of a server breach, making this a more secure alternative to other SSO providers.

I think you misunderstood what I said. I said that it would not be much useful for users who use Keybase as their PGP client. Think about it. Using PGP key in your PGP client to sign in to that client? No way, someone would do that! And even if he/she does, he/she will have to import private key into another client. Well, if they are using another client to sign a message, then I don't think why they should use Keybase as their PGP client. I hope I have made it clear!

• Edited.

[davidar]

Using PGP key in your PGP client to sign in to that client?

@MuhammedZakir No. You aren't logging into keybase. If keybase is your PGP client, then I assume you've already logged into keybase through other means. I'm talking about using your PGP key to sign into websites other than keybase, and keybase acting as a proxy to make that easier. Please re-read my original post.

[MuhammedZakir]

@MuhammedZakir No. You aren't logging into keybase. If keybase is your PGP client, then I assume you've already logged into keybase through other means. I'm talking about using your PGP key to sign into websites other than keybase, and keybase acting as a proxy to make that easier. Please re-read my original post.

Uh, I misunderstood your post! Stupid me!

[zQueal]

This would be a cool idea, but it's inherently insecure. With the absence of 2FA for Keybase all sites which support SSO via Keybase would have a single point of attack. Your Keybase password. For those who have insecure passwords this could be a nightmare as your identity for many sites could be compromised from a single password.

With either forced 2FA for SSO to be enabled or some other more secure method, I'd get behind this...but unfortunately not before.

[MuhammedZakir]

I don't think we need to force 2FA on users for enabling SSO. Of course, its for better security, but forcing doesn't seem good. Facebook, Google etc..., they all have this and they don't force 2FA. So I don't think that's a big issue. IMHO, 2FA should be recommended when SSO is enabled with a short warning/advice. That is better than forcing.

[zQueal]

they all have this and they don't force 2FA

That's really not the point I was trying to make. Keybase isn't attempting to emulate other major /SSOidentity providers--Keybase is trying to be secure. Forcing 2FA for SSO is secure. Allowing users to protect their entire online identity via simple password is not.

[davidar]

With the absence of 2FA for Keybase all sites which support SSO via Keybase would have a single point of attack. Your Keybase password.

Your private key is the 2FA. If you're storing your private key on keybase with an insecure password, then I suspect security isn't your main concern. The security implications for those users are no worse than attackers obtaining your private key, which seems like a bigger concern than SSO spoofing IMO.

[zQueal]

Your private key is the 2FA.

Um. No? If you hold your private key with Keybase it's protected by only your password (not the key itself, mind you, but access to it). If someone were to find/guess/hack/crack your password, then with SSO they could take control of any connected service, too. Which is why I'm really trying to stress the empirical importance of forced 2FA when using Keybase via SSO. Sure, it may be a bit more inconvenient, but protecting your identity and using cryptography isn't easy to begin with.

[davidar]

Ok, let me claify what I mean. There are two situations:

1. Private key is not stored on keybase, so it is a 2FA.
2. Private key is stored on keybase, in which case you value convenience
   over security anyway, especially if you're using an insecure password.
   There are two options for 2FA in this case:
   2a) Cryptographic 2FA (yubikey, mobile app, etc). If users were willing to
   do this, then they may as well store their private key in the yubikey/app,
   and use that for 2FA.
   2b) Trust-based schemes like SMS tokens, which add no extra security in the
   event of a server breach

If there's a third option I've missed, please clarify what kind of 2FA
you're referring to.

If keybase's stance is that a breach of your private key stored on keybase
through password cracking is less serious than SSO spoofing, then I have
some serious concerns about keybase's efforts in "trying to be secure".
You're essentially telling me that keybase thinks that the recommended
practice of storing my private key on keybase is inherently insecure, and
highly vulnerable to attackers.

On Thu, 17 Sep 2015 11:13 Zach Queal notifications@github.com wrote:

Your private key is the 2FA.

Um. No? If you hold your private key with Keybase it's protected by only
your password (not the key itself, mind you, but access to it). If someone
were to find/guess/hack/crack your password, then with SSO they could take
control of any connected service, too. Which is why I'm really trying to
stress the empirical importance of forced 2FA when using Keybase via SSO.
Sure, it may be a bit more inconvenient, but protecting your identity and
using cryptography isn't easy to begin with.

—
Reply to this email directly or view it on GitHub
#1767 (comment)
.

David A Roberts
https://davidar.io

[MuhammedZakir]

@zQueal: That's really not the point I was trying to make. Keybase isn't attempting to emulate other major /SSOidentity providers--Keybase is trying to be secure. Forcing 2FA for SSO is secure. Allowing users to protect their entire online identity via simple password is not.

I got what you said, but I don't think we should force 2FA on users against their wants. However, we should tell them the importance of using 2FA when SSO is enabled.

@MuhammedZakir: IMHO, 2FA should be recommended when SSO is enabled with a short warning/advice. That is better than forcing.

[davidar]

@zQueal Is this the kind of 2FA you were talking about?

https://keybase.io/blog/keybase-new-key-model