sign up with or link email address

[chadwhitacre]

Sign-up would enable a greatly expanded userbase.

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

[chadwhitacre]

(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]

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]

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]

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]

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 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]

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]

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]

+1 from @lindsayp.

[chadwhitacre]

+1 from @LenKendall via Twitter.

[abnor]

+1 in general. Yall's is smart.

[joealcorn]

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]

I personally vouch for Mandrill,seriously love their service.

[chadwhitacre]

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

+1 from @troy in private email.

[mvdkleijn]

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]

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

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

[mvdkleijn]

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]

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]

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

[patcon]

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

[zbynekwinkler]

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]

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

[zbynekwinkler]

👍 👍

[patcon]

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

[duckinator]

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]

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

[chadwhitacre]

+1 moved to #1052 (comment).

[chadwhitacre]

+1 moved to #1052 (comment).

[chadwhitacre]

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.