Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Single Sign On #1767

Open
davidar opened this issue Sep 16, 2015 · 22 comments
Open

Single Sign On #1767

davidar opened this issue Sep 16, 2015 · 22 comments

Comments

@davidar
Copy link

@davidar davidar commented Sep 16, 2015

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
Copy link

@MuhammedZakir MuhammedZakir commented Sep 16, 2015

Loading

@davidar
Copy link
Author

@davidar davidar commented Sep 16, 2015

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

Loading

@MuhammedZakir
Copy link

@MuhammedZakir MuhammedZakir commented Sep 16, 2015

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!

Loading

@davidar
Copy link
Author

@davidar davidar commented Sep 16, 2015

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).

Loading

@MuhammedZakir
Copy link

@MuhammedZakir MuhammedZakir commented Sep 16, 2015

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.

Loading

@davidar
Copy link
Author

@davidar davidar commented Sep 16, 2015

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.

Loading

@MuhammedZakir
Copy link

@MuhammedZakir MuhammedZakir commented Sep 16, 2015

@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!

Loading

@zQueal
Copy link

@zQueal zQueal commented Sep 16, 2015

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.

Loading

@MuhammedZakir
Copy link

@MuhammedZakir MuhammedZakir commented Sep 16, 2015

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.

Loading

@zQueal
Copy link

@zQueal zQueal commented Sep 16, 2015

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.

Loading

@davidar
Copy link
Author

@davidar davidar commented Sep 17, 2015

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.

Loading

@zQueal
Copy link

@zQueal zQueal commented Sep 17, 2015

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.

Loading

@davidar
Copy link
Author

@davidar davidar commented Sep 17, 2015

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

Loading

@MuhammedZakir
Copy link

@MuhammedZakir MuhammedZakir commented Sep 17, 2015

@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.

Loading

@davidar
Copy link
Author

@davidar davidar commented Oct 1, 2015

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

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

Loading

@zQueal
Copy link

@zQueal zQueal commented Oct 1, 2015

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

Definitely. Seems very cumbersome, but would really put most of my worries about this to rest. With this, if a key in your chain got compromised it would only affect certain services, not your entire identity.

Loading

@opn
Copy link

@opn opn commented Mar 4, 2018

I'm interested in this as well. Would use a local server to provide SSO to sites from locally stored keybase pgp keys. Any thoughts on this?

Loading

@wiktor-k
Copy link

@wiktor-k wiktor-k commented Dec 23, 2018

I know this issue is super-old but IndieAuth allows signing in to sites with PGP keys. IndieAuth works as an OpenID provider, presents the user with a challenge to sign and after signing confirms the identity (there is even info about using keybase on their site).

Of course OpenID is not as popular as it was back in the day, but it clearly shows it can be done.

Loading

@gaevoy
Copy link

@gaevoy gaevoy commented Jun 23, 2019

I experimented a bit on how to implement sign-in via Keybase console https://gaevoy.com/2019/06/23/sign-in-via-keybase.html

Also, I deployed my experiment so you can play as well https://app.gaevoy.com/keybase-sign-in/

Loading

@bkeroackdsc
Copy link

@bkeroackdsc bkeroackdsc commented Jun 25, 2019

It would be helpful if the Keybase API supported either an OAuth flow, or at the very least a signature generation endpoint for hosted private keys (authenticated, obviously).

Loading

@xkr47
Copy link

@xkr47 xkr47 commented Aug 26, 2019

Related:

Loading

@nickik
Copy link

@nickik nickik commented Sep 2, 2019

Check out this paper 'KAuth: A Strong Single Sign-On Service based on PKI'. I really think this would be a great feature.

See: https://www.cs.ucy.ac.cy/~eliasathan/papers/secrypt18.pdf

Loading

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
9 participants