Skip to content
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
Closed

sign up with or link email address #89

chadwhitacre opened this issue Jun 29, 2012 · 33 comments
Labels

Comments

@chadwhitacre
Copy link
Contributor

@chadwhitacre 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
Copy link
Contributor Author

@chadwhitacre 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
Copy link
Contributor

@lyndsysimon 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
Copy link
Contributor Author

@chadwhitacre 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
Copy link
Contributor

@lyndsysimon 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
Copy link
Contributor

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

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

@ironchefpython
Copy link

@ironchefpython ironchefpython commented 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?)

@chadwhitacre
Copy link
Contributor Author

@chadwhitacre 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
Copy link
Contributor Author

@chadwhitacre chadwhitacre commented Feb 12, 2013

+1 from @lindsayp.

@chadwhitacre
Copy link
Contributor Author

@chadwhitacre chadwhitacre commented Mar 28, 2013

+1 from @LenKendall via Twitter.

@abnor
Copy link

@abnor abnor commented Mar 30, 2013

+1 in general. Yall's is smart.

@joealcorn
Copy link
Contributor

@joealcorn 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
Copy link
Contributor

@clone1018 clone1018 commented May 2, 2013

I personally vouch for Mandrill,seriously love their service.

@chadwhitacre
Copy link
Contributor Author

@chadwhitacre 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
Copy link
Contributor Author

@chadwhitacre chadwhitacre commented Jul 19, 2013

+1 from @troy in private email.

@mvdkleijn
Copy link
Contributor

@mvdkleijn 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)

@mvdkleijn
Copy link
Contributor

@mvdkleijn 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
Copy link
Contributor

@clone1018 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
Copy link
Contributor

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

@troy 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
Copy link
Contributor Author

@chadwhitacre chadwhitacre commented Sep 2, 2013

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

@patcon
Copy link
Contributor

@patcon 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
Copy link
Contributor

@zwn 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
Copy link
Contributor

@joeyespo 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
Copy link
Contributor

@zwn zwn commented Feb 8, 2014

👍 👍

@patcon
Copy link
Contributor

@patcon patcon commented Feb 8, 2014

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

@duckinator
Copy link
Contributor

@duckinator 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
Copy link
Contributor

@seanlinsley seanlinsley commented Apr 21, 2014

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

@chadwhitacre
Copy link
Contributor Author

@chadwhitacre chadwhitacre commented May 24, 2014

+1 moved to #1052 (comment).

@chadwhitacre
Copy link
Contributor Author

@chadwhitacre chadwhitacre commented May 30, 2014

+1 moved to #1052 (comment).

@chadwhitacre chadwhitacre changed the title sign up with or link email address sign up with ~~or link~~ email address May 30, 2014
@chadwhitacre chadwhitacre changed the title sign up with ~~or link~~ email address sign up with or link email address May 30, 2014
@chadwhitacre
Copy link
Contributor Author

@chadwhitacre 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 mentioned this issue Oct 7, 2014
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.
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
You can’t perform that action at this time.