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

Implement decentralized GPG login #220

Open
paulproteus opened this Issue Jan 27, 2015 · 24 comments

Comments

Projects
None yet
@paulproteus
Member

paulproteus commented Jan 27, 2015

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

This comment has been minimized.

Show comment
Hide comment
@gemlog

gemlog Jan 31, 2015

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.

gemlog commented Jan 31, 2015

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

This comment has been minimized.

Show comment
Hide comment
@matjolic

matjolic Jan 31, 2015

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.

matjolic commented Jan 31, 2015

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

This comment has been minimized.

Show comment
Hide comment
@paulproteus

paulproteus Feb 5, 2015

Member

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.

Member

paulproteus commented Feb 5, 2015

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

This comment has been minimized.

Show comment
Hide comment
@noci2012

noci2012 Feb 28, 2015

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

noci2012 commented Feb 28, 2015

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

@Finkregh

This comment has been minimized.

Show comment
Hide comment
@Finkregh

Finkregh Mar 2, 2015

IMHO that would be something for another issue :-)

Finkregh commented Mar 2, 2015

IMHO that would be something for another issue :-)

@chreekat

This comment has been minimized.

Show comment
Hide comment
@chreekat

chreekat Nov 17, 2015

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.

chreekat commented Nov 17, 2015

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

This comment has been minimized.

Show comment
Hide comment
@elimisteve

elimisteve Feb 20, 2016

Contributor

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

Contributor

elimisteve commented Feb 20, 2016

@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

This comment has been minimized.

Show comment
Hide comment
@elimisteve

elimisteve Feb 20, 2016

Contributor

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

Contributor

elimisteve commented Feb 20, 2016

@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

This comment has been minimized.

Show comment
Hide comment
@noci2012

noci2012 Feb 21, 2016

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

noci2012 commented Feb 21, 2016

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

This comment has been minimized.

Show comment
Hide comment
@elimisteve

elimisteve Mar 4, 2016

Contributor

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.

Contributor

elimisteve commented Mar 4, 2016

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

This comment has been minimized.

Show comment
Hide comment
@noci2012

noci2012 Mar 9, 2016

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.

noci2012 commented Mar 9, 2016

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

This comment has been minimized.

Show comment
Hide comment
@zenhack

zenhack Apr 24, 2016

Contributor

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:

...

Contributor

zenhack commented Apr 24, 2016

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

This comment has been minimized.

Show comment
Hide comment
@kentonv

kentonv Apr 29, 2016

Member

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

Member

kentonv commented Apr 29, 2016

@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

This comment has been minimized.

Show comment
Hide comment
@zenhack

zenhack Apr 29, 2016

Contributor

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.

Contributor

zenhack commented Apr 29, 2016

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

This comment has been minimized.

Show comment
Hide comment
@zenhack

zenhack May 4, 2016

Contributor

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.

Contributor

zenhack commented May 4, 2016

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

This comment has been minimized.

Show comment
Hide comment
@zarvox

zarvox May 11, 2016

Member

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?

Member

zarvox commented May 11, 2016

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

This comment has been minimized.

Show comment
Hide comment
@zenhack

zenhack May 12, 2016

Contributor

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.

Contributor

zenhack commented May 12, 2016

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

This comment has been minimized.

Show comment
Hide comment
@zarvox

zarvox May 12, 2016

Member

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.

Member

zarvox commented May 12, 2016

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

This comment has been minimized.

Show comment
Hide comment
@zenhack

zenhack May 12, 2016

Contributor

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.

Contributor

zenhack commented May 12, 2016

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

This comment has been minimized.

Show comment
Hide comment
@kentonv

kentonv May 16, 2016

Member

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.

Member

kentonv commented May 16, 2016

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

This comment has been minimized.

Show comment
Hide comment
@DEVAHMEDDAOUDI

DEVAHMEDDAOUDI Sep 13, 2017

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 .

DEVAHMEDDAOUDI commented Sep 13, 2017

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

This comment has been minimized.

Show comment
Hide comment
@zenhack

zenhack Sep 13, 2017

Contributor

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.

Contributor

zenhack commented Sep 13, 2017

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

This comment has been minimized.

Show comment
Hide comment
@DEVAHMEDDAOUDI

DEVAHMEDDAOUDI Sep 14, 2017

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.

DEVAHMEDDAOUDI commented Sep 14, 2017

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

This comment has been minimized.

Show comment
Hide comment
@zenhack

zenhack Sep 14, 2017

Contributor

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

Contributor

zenhack commented Sep 14, 2017

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment