Implement decentralized GPG login

[paulproteus]

Right now, self-hosters must choose between Google auth and GitHub auth. This is sub-optimal for people who would prefer to be entirely self-reliant.

This issue tracks work required to deliver the first version of GPG login so that this is a serious option.

[gemlog]

As a self-hoster, this is the holy grail. Well, ssh or gpg keys, I don't really care. Manually adding a few keys to a key ring is fine for self-hosting. Please just get the mechanism there first and then worry about automating it. No one has had a good idea about the latter, ever, so far as I know.

[matjolic]

Implementing such a feature would be really awesome for self-hosting apps. A cool project to take a look at that has tackled the idea is monkeysphere, though their browser plugin only supports Firefox for the time being.

[paulproteus]

That's great that monkeysphere has been looking into this! Thanks for
linking to it. I'll ping dkg and other Monkeysphere people to find out if
it would be a good fit.

[noci2012]

another options to allow personal certificates, and be able to install a CA certificate. (xca can be used to issue/revoke certificates ..)

[Finkregh]

IMHO that would be something for another issue :-)

[chreekat]

Unsure whether this should be an entirely different ticket, but for your consideration: IndieAuth! It is not a very widely used service, but I think it has great potential.

[elimisteve]

@paulproteus By GPG login do you mean via some sort of challenge/response mechanism? Like if I want to login as user@domain.com, Sandstorm grabs my GPG pubkey from Keybase, encrypts a challenge to me, I decrypt it, then I paste that into a web form (or paste in the answer encrypted with the server's pubkey) to log in?

[elimisteve]

@noci2012 Personal certs are interesting, but perhaps difficult to distribute?

@chreekat IndieAuth is pretty sweet, but having something more cryptographically secure sounds nice... Perhaps combining IndieAuth with grabbing a given user's GPG key from Keybase could work?

[noci2012]

why, you obtain them from a CA...
Create a CSR where the email address is the subject, and ask a CA (f.e. cacert.org), but can be ANY CA that you trust to sign them. downlaod them from their secured website and done.

If someone creates a a private CA and signs through that, is just mean the Public key of the Selfowned CA must be in the trusted store on the "server", or in the path the "Service" uses.

This is equivalent to Login by mail adres.... where the mail adres is signed by a Trusted CA and the trusted CA is known in the trusted CA list. The same certificate can be used to sign or encrypt mail (S/MIME).

XCA is a good tool to manage a private CA..., http://xca.sourceforge.net

[elimisteve]

Explanation of this from @kentonv in this post on sandstorm-dev:

The GPG login plan is actually even more anonymous: there is no email involved, just a key pair. The user's "identity" is their key fingerprint. They log in by proving they own the corresponding private key.

[noci2012]

And through the fingerprint & id the remainder of info & web of trust can be checked. (who trusts who, who cosigned the GPG and to what level, including mail addresses).
An email address in a CA certificate can be a fake one as well IF the CA accepts that.
With xca ( http://xca.sourceforge.net/ ) you can issue your own certificate(s) based on private CA if you like.

[zenhack]

Is there any work on this actually happening? With the fingerprint-as-identity solution, I'm envisioning part of a sign-in page that looks something like:

Please run the command:

echo 'I authorize sign-in #52 to example.sandcats.io as C0B2C432638DAEB0D70715C7F654B8C7D4CA3CB8 on So 24 Apr 2016 04:51:29 EDT' | gpg --armor --detach-sign

And paste the result below:

...

[kentonv]

@zenhack Relevant: https://sandstorm.io/news/2015-05-01-is-that-ascii-or-protobuf

Though probably the answer to that problem here is to say: "You need to use a signing key that you only use for signing natural language text."

Another thing to consider: If we used decryption rather than signing, then we could actually store a symmetric key encrypted to your public key, and encrypt all your data on the server with that symmetric key, such that there's no way for Sandstorm to access your data at rest (only when you log in). However, there is a risk that users will unwittingly turn into a decryption oracle for their Sandstorm server.

Otherwise, yes, that's more or less what I'd like to implement. But no, there is no work happening on this currently -- too much other stuff to do. If you'd like to work on it, that'd be cool!

[zenhack]

Ok, yeah, wow.

My immediate thought is "how many developers can I find in the wild who sign packages, git tags and emails with the same key?"

"You need to use a signing key that you only use for signing natural language text" sounds more much like "You should use a different password for every site" than I'm comfortable with -- my bet is many people won't. Doesn't diminish the importance of the advice (in either case).

I will need to think about this.

[zenhack]

Maybe the thing to do is just document that pitfall right on the login page itself; might actually raise some awareness of the issue.

Perhaps as a mitigating measure we should look at other popular things GPG is used to sign; distro packages, git tags, whatever monkey sphere does... and craft the string format to avoid collisions with those. This way, an attacker would at least need to make the string look different from what the user usually sees, even if it otherwise seems innocuous.

[zarvox]

I'm inclined to say that GPG login should probably be attached to an email identity rather than a separate type of identity for a couple of reasons:

• Sandstorm still needs to send email notifications in various circumstances, like when a grain is shared with you. Also, a user claiming to Sandstorm that a GPG key is associated with an email address is not sufficient evidence of ownership of that email address for Sandstorm to trust it; we'd have to send an email to confirm address ownership anyway.
• GPG encryption/decryption has some existing integration with mail software.
• Entering your key ID and copy-pasting large blocks of ascii-armored GPG stuff back and forth is pretty lousy UX, to the point that I think friction will be so high and adoption so low (especially when considering GPG's already-tiny userbase) that it becomes exceedingly unlikely users will get much value out of this.

This proposal does have its downsides - my GPG key id is stable in a way email addresses added/removed might not be, and multiple emails associated with the same GPG key would wind up being different identities. I think these drawbacks are less problematic than the UX issues described above, and that in practice, very few users will be impacted. I'd like to hear what others think, though!

A possible setup flow would be:

1. User signs in via email token
2. User goes to accounts page
3. User provides their GPG public key in a <textarea>
4. Server encrypts a message with a secret link to that key, and sends it to the address the user has on file.
5. User fetches mail, decrypts with their GPG private key, and opens link or enters the token into the UI.

Then, future emails (including login token emails) delivered to that email address would be encrypted to the public key on file.

Thoughts?

[zenhack]

Question: How do email notifications work with github login?

Observation: what you propose is basically just the existing email login
except that the token emails are encrypted.

I don't know that I think the UX is going to be much worse than the "go
check your email" already is (which is actually rather annoying).
Either way I have to open a new window, authenticate against something
else, then shuffle the data back myself.

I do think this is fairly niche. IIRC correctly, this issue dates back
to the days before email login was a thing; it was github or gmail. That
had the really obvious problem of forcing people to rely on one of two
large corporations. The email solution doesn't have that drawback; maybe
we should step back and ask what problem we're actually trying to
address at this point.

[zarvox]

Question: How do email notifications work with github login?

Good question! GitHub provides a set of verified email addresses, and we trust those. You can see the email addresses you've proven to Sandstorm at e.g. https://oasis.sandstorm.io/account . If you haven't proven any email address to GitHub, then it'll just be your GitHub noreply address, and that is indeed sad UX because then you won't have any way to receive notifications from the server, and probably won't know that you're missing anything.

Perhaps that should be filed as a separate bug, but I don't think I know very many GitHub users that don't have even a single email address confirmed, so hopefully it's not too serious.

Observation: what you propose is basically just the existing email login
except that the token emails are encrypted.

Yep, good summary. We could also potentially encrypt any other email intended for the user with the public key on file.

I don't know that I think the UX is going to be much worse than the "go
check your email" already is (which is actually rather annoying).
Either way I have to open a new window, authenticate against something
else, then shuffle the data back myself.

A fair point.

I do think this is fairly niche. IIRC correctly, this issue dates back
to the days before email login was a thing; it was github or gmail. That
had the really obvious problem of forcing people to rely on one of two
large corporations. The email solution doesn't have that drawback; maybe
we should step back and ask what problem we're actually trying to
address at this point.

Hmm, interesting observation. I've got two answers for "what unsolved problem does this potentially solve" (and would welcome hearing others I've missed):

• encrypt all email to a user (keep user communication confidential)

I suspect that the Tor folks would still like it if they could make their email login codes and sharing links not be leaked to the NSA every time they try to login, since it's known from the XKeyscore rules that @torproject.org addresses are actively snooped on. So that's a usecase for the "encrypt all emails to a user" workflow. Facebook has implemented this sort of feature, though I expect it's also pretty niche: https://www.facebook.com/notes/protecting-the-graph/securing-email-communications-from-facebook/1611941762379302

• higher assurance authentication

There's also the "I want something even higher-assurance authentication than Google or GitHub or email provide, and I believe I am very competent at managing secrets" workflow. That set of users are probably served similarly well by some flavor of 2FA (which I have ideas for and am thinking about how I might also support U2F). In a sense, if GPG key is not your "identity", it is instead one type of "second factor" that you could use to prove ownership of an account.

Either of these are problems that I think are still worth solving, and which GPG might help with in some way. That said, especially for "higher-assurance-user-authentication", I think we can build a thing which is better at protecting more users if we eschew GPG than if we use it.

[zenhack]

I think those are good use cases. Perhaps the PGP thing could actually be orthoginal to the login type; essentially a "when you send me email, encrypt it" checkbox. Might be beter than the proliferation of more login options (esp. with things that are somewhat niche); I think this could be fairly non-intrusive.

Random thought: Github semi-recently provided the ability to register public keys with your account.

[kentonv]

Hmm, it would be interesting to be able to tell Sandstorm to PGP-encrypt all email sent to my address. For that reason alone I'd say that focusing on adding PGP as a modifier to existing identities, rather than a new kind of identity, makes sense.

I still do think that having an identity type that is actually a public key would be useful. Arguably, having a verified email address is not necessary if we also deliver all emails as bell-menu notifications. Public-key-identity users could be told that they will need to log in regularly to see notifications.

But perhaps implementing PGP-encrypted email first makes sense.

[DEVAHMEDDAOUDI]

Hello,
So have you solved your problem? I can not connect with a "normal" email address, I can only connect with a Gmail address. How to do ? I activated SMTP 25 in my server. Help me . Thank you

Ahmed DAOUDI .

[zenhack]

So, this issue isn't really related to your problem -- standard email login should work fine.

Also, for email login you don't actually need the server to be able to receive email, only send it. How have you configured mail on your sandstorm box? Admin panel -> email configuration.

[DEVAHMEDDAOUDI]

Hello @zenhack

I don't know what to put in the "SMTP HOST"

For the "PORT" I put "25", I also tried with "2525" as seen in a forum but it does not work.

The fields "Username (optional)" and "Password (optional)" are left blank.

I would like to be able to send emails to other users, and they can create an account with a different address than Gmail. I have a 500 internal server error when I try to send out the invitation, and when I copy the registration link and try to force it to register (without going through the mail reception, can not create an account).

Do you have any idea where my problem will come from?

Thank you ...

Ahmed DAOUDI.

[zenhack]

@DEVAHMEDDAOUDI, I think you're misunderstanding how that panel works. You need an SMTP server you can use to send email, those settings specify how to connect to it (port 25 is for receiving email, which isn't relevant to sending login emails). If you don't otherwise have something mailgun isn't a bad option. Once you've got that set up, you'll need to input the information provided by mailgun into the admin panel; for mailgun you'd put in smtp.mailgun.org as the host and port 587 as the port, and you'll need to get the username/password/email address from them.

[jonpavelich]

Any updates on this? It seems like two separate issues are being discussed: using a PGP key pair as an identity, and having the server encrypt all email to you with PGP. I'd love to see both of these!

[zenhack]

@jonpavelich, I don't believe anything has changed on this front, no.

[fire]

Posting the idea it's possible via crypto coin accounts to have a crypto identity and a mailbox for it (Airdrop).

Using something like DIDs or webfinger where it's a URI with a well known folder for a specific identity at a home server is possible too.