This repository has been archived by the owner. It is now read-only.

sign up with or link email address #89

Closed
chadwhitacre opened this Issue Jun 29, 2012 · 33 comments

Comments

Projects
None yet
@chadwhitacre
Contributor

chadwhitacre commented Jun 29, 2012

Sign-up would enable a greatly expanded userbase.

Link would enable notifications (see, e.g., #88; see also #73 for GitHub notifications).

@chadwhitacre

This comment has been minimized.

Show comment
Hide comment
@chadwhitacre

chadwhitacre Aug 21, 2012

Contributor

(Note to self) Read this:

"Why passwords have never been weaker—and crackers have never been stronger"

http://arstechnica.com/security/2012/08/passwords-under-assault/

Contributor

chadwhitacre commented Aug 21, 2012

(Note to self) Read this:

"Why passwords have never been weaker—and crackers have never been stronger"

http://arstechnica.com/security/2012/08/passwords-under-assault/

@lyndsysimon

This comment has been minimized.

Show comment
Hide comment
@lyndsysimon

lyndsysimon Sep 23, 2012

Contributor

I believe this could be done entirely without passwords.

Option 1: When a user tries to log in, send an email with a login token. Expire the token in an hour or other reasonably short time frame. Note - email is insecure and can be eavesdropped, but most sites already implement email-based password recovery, so this is in theory no less secure.

Option 2: When a user tries to log in, send an email with a login token and display a randomly selected dictionary word on the site (via SSL). Require the user to enter this word after they use the email link. This increases the difficulty of logging in somewhat, but as far as I can see actually offers improved security over a traditional password-based system.

Contributor

lyndsysimon commented Sep 23, 2012

I believe this could be done entirely without passwords.

Option 1: When a user tries to log in, send an email with a login token. Expire the token in an hour or other reasonably short time frame. Note - email is insecure and can be eavesdropped, but most sites already implement email-based password recovery, so this is in theory no less secure.

Option 2: When a user tries to log in, send an email with a login token and display a randomly selected dictionary word on the site (via SSL). Require the user to enter this word after they use the email link. This increases the difficulty of logging in somewhat, but as far as I can see actually offers improved security over a traditional password-based system.

@chadwhitacre

This comment has been minimized.

Show comment
Hide comment
@chadwhitacre

chadwhitacre Sep 25, 2012

Contributor

You're ahead of your time, @lyndsysimon. Just saw this on HN:

Most web sites ask for a password when you register. After logging in, you can access the site until your session expires. When you forget your password, you can request an email with a link to a password change form.

NoPassword factors out the password from this process. You register with an email address and receive a link that gives you a session on that browser until you log out. If you ever need to log in from somewhere else, you can request another email with a link that will log you in wherever you are.

https://nopassword.alexsmolen.com/

Contributor

chadwhitacre commented Sep 25, 2012

You're ahead of your time, @lyndsysimon. Just saw this on HN:

Most web sites ask for a password when you register. After logging in, you can access the site until your session expires. When you forget your password, you can request an email with a link to a password change form.

NoPassword factors out the password from this process. You register with an email address and receive a link that gives you a session on that browser until you log out. If you ever need to log in from somewhere else, you can request another email with a link that will log you in wherever you are.

https://nopassword.alexsmolen.com/

@lyndsysimon

This comment has been minimized.

Show comment
Hide comment
@lyndsysimon

lyndsysimon Sep 25, 2012

Contributor

I wish I could take credit for it, but I read about it a few months ago and couldn't find the reference.

The eavesdropping issue is real, though. Recovery emails aren't sent very often, but if websites used that for login regularly I'm afraid that email interception for the purpose of obtaining login tokens would be much more common. You could limit it by IP as well, but nothing is going to be as secure as a pre-shared secret (like a password).

ETA: the link you provided verifies IP.

Contributor

lyndsysimon commented Sep 25, 2012

I wish I could take credit for it, but I read about it a few months ago and couldn't find the reference.

The eavesdropping issue is real, though. Recovery emails aren't sent very often, but if websites used that for login regularly I'm afraid that email interception for the purpose of obtaining login tokens would be much more common. You could limit it by IP as well, but nothing is going to be as secure as a pre-shared secret (like a password).

ETA: the link you provided verifies IP.

@lyndsysimon

This comment has been minimized.

Show comment
Hide comment
@lyndsysimon

lyndsysimon Sep 25, 2012

Contributor

Actually, now that I'm considering it, limiting the login token to a single IP might do the trick. It's transparent to the user, and while an attacker can spoof source IPs I don't belive th would be able to see the returned (via SSL) authentication cookie since it isn't routed to the them.

You'd have to do a man in the middle attack, and if you can do that you can hijack a traditional login session as well.

I'm going to consider writing a proof-of-concept module for Flask (and maybe Aspen) that does this, and see if anyone can tear the idea apart. It's slightly above my level of technical competence, but within reach.

Contributor

lyndsysimon commented Sep 25, 2012

Actually, now that I'm considering it, limiting the login token to a single IP might do the trick. It's transparent to the user, and while an attacker can spoof source IPs I don't belive th would be able to see the returned (via SSL) authentication cookie since it isn't routed to the them.

You'd have to do a man in the middle attack, and if you can do that you can hijack a traditional login session as well.

I'm going to consider writing a proof-of-concept module for Flask (and maybe Aspen) that does this, and see if anyone can tear the idea apart. It's slightly above my level of technical competence, but within reach.

@singpolyma

This comment has been minimized.

Show comment
Hide comment
@singpolyma

singpolyma Oct 13, 2012

This feature makes me uncomfortable. Especially if passwords are involved.

Email verification for login is a bit better than passwords, but since I'm not sure what problem this feature would be trying to solve, I'm not sure if that would be acceptable.

This feature makes me uncomfortable. Especially if passwords are involved.

Email verification for login is a bit better than passwords, but since I'm not sure what problem this feature would be trying to solve, I'm not sure if that would be acceptable.

@ironchefpython

This comment has been minimized.

Show comment
Hide comment
@ironchefpython

ironchefpython Oct 13, 2012

I'm not sure what problem this feature would be trying to solve, I'm not sure if that would be acceptable.

There exists a set of people who have nothing to say on twitter, and who do not contribute to open source projects hosted on github. Should these people not be allowed to tip, or should they be required to sign up for a github account that they will never use again?

The eavesdropping issue is real... [but email isn't] going to be as secure as a pre-shared secret (like a password).

I would suggest that gmail with two-factor authentication is going to be more secure than anything you can easily hack up, especially since you need a password reset mechanism, and most people use email for that purpose. (so as long as you're using it as a backup authentication mechanism, why not go all the way and use it as the primary?)

I'm not sure what problem this feature would be trying to solve, I'm not sure if that would be acceptable.

There exists a set of people who have nothing to say on twitter, and who do not contribute to open source projects hosted on github. Should these people not be allowed to tip, or should they be required to sign up for a github account that they will never use again?

The eavesdropping issue is real... [but email isn't] going to be as secure as a pre-shared secret (like a password).

I would suggest that gmail with two-factor authentication is going to be more secure than anything you can easily hack up, especially since you need a password reset mechanism, and most people use email for that purpose. (so as long as you're using it as a backup authentication mechanism, why not go all the way and use it as the primary?)

@chadwhitacre

This comment has been minimized.

Show comment
Hide comment
@chadwhitacre

chadwhitacre Nov 2, 2012

Contributor

In our first exercise in fraud prevention (#329), the vitality of linked Twitter and GitHub accounts has been the determining factor in suspending accounts. Since measures of vitality are not similarly associated with email accounts—I can't publicly see your social network graph given your email address—it seems that email-only registrations would make it harder to detect money laundering. Therefore, I suggest that we allow linking an email address to an existing Gittip account, but don't allow creating a new Gittip account using only an email address.

Contributor

chadwhitacre commented Nov 2, 2012

In our first exercise in fraud prevention (#329), the vitality of linked Twitter and GitHub accounts has been the determining factor in suspending accounts. Since measures of vitality are not similarly associated with email accounts—I can't publicly see your social network graph given your email address—it seems that email-only registrations would make it harder to detect money laundering. Therefore, I suggest that we allow linking an email address to an existing Gittip account, but don't allow creating a new Gittip account using only an email address.

@chadwhitacre

This comment has been minimized.

Show comment
Hide comment
@chadwhitacre

chadwhitacre Feb 12, 2013

Contributor

+1 from @lindsayp.

Contributor

chadwhitacre commented Feb 12, 2013

+1 from @lindsayp.

@chadwhitacre

This comment has been minimized.

Show comment
Hide comment
@chadwhitacre

chadwhitacre Mar 28, 2013

Contributor

+1 from @LenKendall via Twitter.

Contributor

chadwhitacre commented Mar 28, 2013

+1 from @LenKendall via Twitter.

@abnor

This comment has been minimized.

Show comment
Hide comment
@abnor

abnor Mar 30, 2013

+1 in general. Yall's is smart.

abnor commented Mar 30, 2013

+1 in general. Yall's is smart.

@joealcorn

This comment has been minimized.

Show comment
Hide comment
@joealcorn

joealcorn May 2, 2013

Contributor

It seems this is blocking a lot of tickets so I made a start on this tonight. feedback welcomed of course

joealcorn@ebe1fea

@whit537 How are you planning to send the emails? a service like mandrill/mailgun/sendgrid, your own mail servers, something else?

Contributor

joealcorn commented May 2, 2013

It seems this is blocking a lot of tickets so I made a start on this tonight. feedback welcomed of course

joealcorn@ebe1fea

@whit537 How are you planning to send the emails? a service like mandrill/mailgun/sendgrid, your own mail servers, something else?

@clone1018

This comment has been minimized.

Show comment
Hide comment
@clone1018

clone1018 May 2, 2013

Contributor

I personally vouch for Mandrill,seriously love their service.

Contributor

clone1018 commented May 2, 2013

I personally vouch for Mandrill,seriously love their service.

@chadwhitacre

This comment has been minimized.

Show comment
Hide comment
@chadwhitacre

chadwhitacre May 3, 2013

Contributor

@buttscicles Woo-hoo, great start on this, thanks! I'll provide more comments inline.

I'd like to use a hosted service that has a Heroku plugin. All three mentioned do. I did a quick review of those three and am having a hard time seeing the difference on paper. Let's plan to use Mandrill, I guess, because it's cheaper and because MailChimp and because @clone1018. :-)

Contributor

chadwhitacre commented May 3, 2013

@buttscicles Woo-hoo, great start on this, thanks! I'll provide more comments inline.

I'd like to use a hosted service that has a Heroku plugin. All three mentioned do. I did a quick review of those three and am having a hard time seeing the difference on paper. Let's plan to use Mandrill, I guess, because it's cheaper and because MailChimp and because @clone1018. :-)

@chadwhitacre

This comment has been minimized.

Show comment
Hide comment
@chadwhitacre

chadwhitacre Jul 19, 2013

Contributor

+1 from @troy in private email.

Contributor

chadwhitacre commented Jul 19, 2013

+1 from @troy in private email.

@mvdkleijn

This comment has been minimized.

Show comment
Hide comment
@mvdkleijn

mvdkleijn Aug 12, 2013

Contributor

If I were a hacker, I'd love Gittip to implement password less (email only) logins. The assumption that people are using a secure email provider like GMail is ridiculous. (assuming GMail is secure, which I wouldn't if I were you)

I'd prefer Gittip allowing people to login with something a little more secure like a Yubikey. (see #1322)

Contributor

mvdkleijn commented Aug 12, 2013

If I were a hacker, I'd love Gittip to implement password less (email only) logins. The assumption that people are using a secure email provider like GMail is ridiculous. (assuming GMail is secure, which I wouldn't if I were you)

I'd prefer Gittip allowing people to login with something a little more secure like a Yubikey. (see #1322)

@clone1018

This comment has been minimized.

Show comment
Hide comment
@clone1018

clone1018 Aug 12, 2013

Contributor

Gittip's main audience is everyone, not specifically hackers. I'm just a developer and personally I'd opt out of having to pull out whatever that is each time I want to login. Passwords or external service auth will win me over every time.

Contributor

clone1018 commented Aug 12, 2013

Gittip's main audience is everyone, not specifically hackers. I'm just a developer and personally I'd opt out of having to pull out whatever that is each time I want to login. Passwords or external service auth will win me over every time.

@clone1018

This comment has been minimized.

Show comment
Hide comment
@clone1018

clone1018 Aug 12, 2013

Contributor

But then again I'm also against solely logging into Gittip with an email. You should have an external service linked for better fact checking before you take the plunge and tip.

Contributor

clone1018 commented Aug 12, 2013

But then again I'm also against solely logging into Gittip with an email. You should have an external service linked for better fact checking before you take the plunge and tip.

@mvdkleijn

This comment has been minimized.

Show comment
Hide comment
@mvdkleijn

mvdkleijn Aug 12, 2013

Contributor

@clone1018 My "if i were a hacker" remark was to show that I think password-less, email only logins are a bad thing. It would make hacking Gittip easy.

Contributor

mvdkleijn commented Aug 12, 2013

@clone1018 My "if i were a hacker" remark was to show that I think password-less, email only logins are a bad thing. It would make hacking Gittip easy.

@clone1018

This comment has been minimized.

Show comment
Hide comment
@clone1018

clone1018 Aug 12, 2013

Contributor

Oh, gah, I hate that word. I thought you meant the overly softened "anyone who modifies something" ycombinator definition :P. Sorry.

Contributor

clone1018 commented Aug 12, 2013

Oh, gah, I hate that word. I thought you meant the overly softened "anyone who modifies something" ycombinator definition :P. Sorry.

@mvdkleijn

This comment has been minimized.

Show comment
Hide comment
@mvdkleijn

mvdkleijn Aug 12, 2013

Contributor

yeah no problem, I get where you're coming from... I used to correct people and say "crackers are the bad guys, hackers the good guys" but I finally gave up 😄

Contributor

mvdkleijn commented Aug 12, 2013

yeah no problem, I get where you're coming from... I used to correct people and say "crackers are the bad guys, hackers the good guys" but I finally gave up 😄

@troy

This comment has been minimized.

Show comment
Hide comment
@troy

troy Aug 12, 2013

My example is close to #89 (comment), except that it's dumber: I just want a simple way to support open-source apps, despite having a 4-letter GitHub username :-)

I perceive that https://www.gittip.com/about/fraud/2012-11-05.html was painful enough to imprint a deep – maybe unreasonably deep – institutional memory with Gittip. While fraud is certainly a real issue, creating a Twitter account for "Throw A. Away" isn't going to make it go away.

If the goal is to make fraud easier to confirm while the volume is low (rather than to stop it), some other possibilities:

  • pause a user's account and request info out-of-band
  • set a cap which lets users build some familiarity with the service first (delpan was in the top 10 almost immediately)

I should add that I can completely understand not implementing this due to lack of time (compared to the number of people who decline to use existing methods). I'm only bringing it up because as a fraud prevention mechanism, it seems like less-blunt methods might have similar results.

troy commented Aug 12, 2013

My example is close to #89 (comment), except that it's dumber: I just want a simple way to support open-source apps, despite having a 4-letter GitHub username :-)

I perceive that https://www.gittip.com/about/fraud/2012-11-05.html was painful enough to imprint a deep – maybe unreasonably deep – institutional memory with Gittip. While fraud is certainly a real issue, creating a Twitter account for "Throw A. Away" isn't going to make it go away.

If the goal is to make fraud easier to confirm while the volume is low (rather than to stop it), some other possibilities:

  • pause a user's account and request info out-of-band
  • set a cap which lets users build some familiarity with the service first (delpan was in the top 10 almost immediately)

I should add that I can completely understand not implementing this due to lack of time (compared to the number of people who decline to use existing methods). I'm only bringing it up because as a fraud prevention mechanism, it seems like less-blunt methods might have similar results.

@chadwhitacre

This comment has been minimized.

Show comment
Hide comment
@chadwhitacre

chadwhitacre Sep 2, 2013

Contributor

+1 from @jonathan-s on #1366, with the added idea of pulling an email address from GitHub OAuth.

Contributor

chadwhitacre commented Sep 2, 2013

+1 from @jonathan-s on #1366, with the added idea of pulling an email address from GitHub OAuth.

@patcon

This comment has been minimized.

Show comment
Hide comment
@patcon

patcon Nov 23, 2013

Contributor

Was thinking about starting a new issue titled "Make gittip more accessible to those responsible for finance within companies using gittip", but it seemed it might fit here as a use-case:

The person who manages my company's finances prefers services where it's possible to have a billing account. This doesn't necessarily need to be restricted in any way, but the main thing is that we shouldn't need to give the accountant access to the company Twitter account in order for them to easily access invoices and manage credit card info. That is just asking for a world of trouble, because it's easy for someone to do some damage if they forget they're logged in. Similar concerns for making them use github or any 3rd party login. Login via email would go long way toward solving this.

Let me know if this topic deserves it's own issue :)

Contributor

patcon commented Nov 23, 2013

Was thinking about starting a new issue titled "Make gittip more accessible to those responsible for finance within companies using gittip", but it seemed it might fit here as a use-case:

The person who manages my company's finances prefers services where it's possible to have a billing account. This doesn't necessarily need to be restricted in any way, but the main thing is that we shouldn't need to give the accountant access to the company Twitter account in order for them to easily access invoices and manage credit card info. That is just asking for a world of trouble, because it's easy for someone to do some damage if they forget they're logged in. Similar concerns for making them use github or any 3rd party login. Login via email would go long way toward solving this.

Let me know if this topic deserves it's own issue :)

@zwn

This comment has been minimized.

Show comment
Hide comment
@zwn

zwn Nov 23, 2013

Contributor

As I have noted before (#756 (comment)) I think in the future we will need to rethink how we do sign in anyway. Associating the company twitter account is one thing (to prove the link for fraud protection) but using it to sign in every time is another. I think this will be one of the issues to talk about at the retreat (as to what implement next, aka the roadmap).

Contributor

zwn commented Nov 23, 2013

As I have noted before (#756 (comment)) I think in the future we will need to rethink how we do sign in anyway. Associating the company twitter account is one thing (to prove the link for fraud protection) but using it to sign in every time is another. I think this will be one of the issues to talk about at the retreat (as to what implement next, aka the roadmap).

@joeyespo

This comment has been minimized.

Show comment
Hide comment
@joeyespo

joeyespo Feb 7, 2014

Contributor

(Not sure where to post this, so putting it here.)

I know this isn't a popular opinion here, but I believe we should require accounts to be linked with email. Not only is it a standard practice of nearly every business out there--for good reason, an email address still the absolute best way to engage with your customers--it's the best way to alert people when something good happens and, more importantly, when something goes wrong.

For example, last week I found out someone stole my credit card and made purchases with it. Luckily my bank called me to let me know they shut down the account and sent me another card. The thing is, now I have to go and re-enter my card on all my accounts. I have no idea how many are out there. Gittip already had a failed credit card attempt, and yet I received no indication that anything was wrong until I manually logged back in. In my case, I know Gittip well and so fixed the problem right away, but this could very well be a service that someone else sets and forgets, and therefore doesn't address the problem for months.

So really, is there another way we can reach out to people whose account needs to take action? I personally don't think there's a better way than email, but am open to suggestions.

Contributor

joeyespo commented Feb 7, 2014

(Not sure where to post this, so putting it here.)

I know this isn't a popular opinion here, but I believe we should require accounts to be linked with email. Not only is it a standard practice of nearly every business out there--for good reason, an email address still the absolute best way to engage with your customers--it's the best way to alert people when something good happens and, more importantly, when something goes wrong.

For example, last week I found out someone stole my credit card and made purchases with it. Luckily my bank called me to let me know they shut down the account and sent me another card. The thing is, now I have to go and re-enter my card on all my accounts. I have no idea how many are out there. Gittip already had a failed credit card attempt, and yet I received no indication that anything was wrong until I manually logged back in. In my case, I know Gittip well and so fixed the problem right away, but this could very well be a service that someone else sets and forgets, and therefore doesn't address the problem for months.

So really, is there another way we can reach out to people whose account needs to take action? I personally don't think there's a better way than email, but am open to suggestions.

@zwn

This comment has been minimized.

Show comment
Hide comment
@zwn

zwn Feb 8, 2014

Contributor

👍 👍

Contributor

zwn commented Feb 8, 2014

👍 👍

@patcon

This comment has been minimized.

Show comment
Hide comment
@patcon

patcon Feb 8, 2014

Contributor

@joeyespo what you're saying makes a lot of sense 👍

Contributor

patcon commented Feb 8, 2014

@joeyespo what you're saying makes a lot of sense 👍

@duckinator

This comment has been minimized.

Show comment
Hide comment
@duckinator

duckinator Apr 2, 2014

Contributor

A very late +1, for the very reasons @joeyespo mentions.

There's currently an 8 month old outstanding pull request (#1287) for this. How do we want to move forward?

Contributor

duckinator commented Apr 2, 2014

A very late +1, for the very reasons @joeyespo mentions.

There's currently an 8 month old outstanding pull request (#1287) for this. How do we want to move forward?

@seanlinsley

This comment has been minimized.

Show comment
Hide comment
@seanlinsley

seanlinsley Apr 21, 2014

Contributor

#2303 has been merged, which adds initial support for email addresses. We still need a confirmation flow, though.

Contributor

seanlinsley commented Apr 21, 2014

#2303 has been merged, which adds initial support for email addresses. We still need a confirmation flow, though.

@chadwhitacre

This comment has been minimized.

Show comment
Hide comment
@chadwhitacre

chadwhitacre May 24, 2014

Contributor

+1 moved to #1052 (comment).

Contributor

chadwhitacre commented May 24, 2014

+1 moved to #1052 (comment).

@chadwhitacre

This comment has been minimized.

Show comment
Hide comment
@chadwhitacre

chadwhitacre May 30, 2014

Contributor

+1 moved to #1052 (comment).

Contributor

chadwhitacre commented May 30, 2014

+1 moved to #1052 (comment).

@chadwhitacre chadwhitacre changed the title from sign up with or link email address to sign up with ~~or link~~ email address May 30, 2014

@chadwhitacre chadwhitacre changed the title from sign up with ~~or link~~ email address to sign up with or link email address May 30, 2014

@chadwhitacre

This comment has been minimized.

Show comment
Hide comment
@chadwhitacre

chadwhitacre May 30, 2014

Contributor

After reviewing this and #1052, I'm calling this done with #2303. We can now link email addresses! Yay! :-)

Let's use #1052 for email registration.

Contributor

chadwhitacre commented May 30, 2014

After reviewing this and #1052, I'm calling this done with #2303. We can now link email addresses! Yay! :-)

Let's use #1052 for email registration.

@chadwhitacre chadwhitacre referenced this issue Oct 7, 2014

Merged

Email - Part 1 #2752

33 of 35 tasks complete

@chadwhitacre chadwhitacre reopened this Oct 14, 2014

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