Live data from Hacker News

The "email is authentication" pattern

rubenerd.com

341–350 of 474 posts

Re: The "email is authentication" pattern

#341
post #66

At this point why not just pass a one-time url link to your email address, and have it be a single click to login? Have it expire within 10 mins if not used, and be one-time use disposable. Still, anyone who has the link initially should be able to login with your account - but it's only accessible from your email. Obliterates all sense of security beyond the email account itself, but that's where we're at anyway. Do…

I do this for many of my web apps, it's confusing to users ("why do I already have an account here? I never signed up!"), expensive (email sending isn't free) and slow (sometimes the emails go to spam, sometimes they get greylisted and people can't log in for hours, sometimes it takes a minute to arrive and that's way too long to wait), etc. I don't know if I'd recommend it.

I hate when services only use SMS for 2FA. Sometimes I have to stare at my messages for a few dozen seconds to get the code, but with standard 2FA it takes me half a dozen seconds to unlock my phone and get the code.

Re: The "email is authentication" pattern

#342

We run a pretty unserious business. That is, our users use our accounts only out of convenience. The system we've settled on is this: 1. User enters email 2. We send a verification code to their email 3. User enters code, is signed in "indefinitely" (very, very long cookie) Whether or not they had an account before hand is irrelevant, we just register a new account if the email is new. The occasional user has multipl…

This is also (from the data that I have seen) by far the best approach to maximise ecommerce revenue.

Don't force buyers into an account, just ask their details (the browser will autocomplete anyway). Send an email afterwards with a link to check their order status. Next order, ask for their email again.

Any extra friction costs more in lost revenue than the benefits of having "signed up" users.

Re: The "email is authentication" pattern

#343
post #320
post #139

Earlier quoted context omitted.

I don't know, we carried physical money for millenia. Humans managed that.

Banks have been a thing almost as long as money.

And the notion of credit has been a thing even longer than both money and banks. You don't need to carry money around for every little transaction if people know you're good for it someday in the the future.

Re: The "email is authentication" pattern

#344

I am one of those people who always clicks "forgot password", and sorry but it's actually fine. I type a long, completely nonsense sequence of words and characters for my new password, then ctrl-c to copy, then log in with that password, and then promptly forget it. It cannot be more secure to store it in a password manager than not to store it at all. The email recovery path exists in either case, so that part is a…

you may lose the email

Re: The "email is authentication" pattern

#345

We run a pretty unserious business. That is, our users use our accounts only out of convenience. The system we've settled on is this: 1. User enters email 2. We send a verification code to their email 3. User enters code, is signed in "indefinitely" (very, very long cookie) Whether or not they had an account before hand is irrelevant, we just register a new account if the email is new. The occasional user has multipl…

This is also (from the data that I have seen) by far the best approach to maximise ecommerce revenue. Don't force buyers into an account, just ask their details (the browser will autocomplete anyway). Send an email afterwards with a link to check their order status. Next order, ask for their email again. Any extra friction costs more in lost revenue than the benefits of having "signed up" users.

Wouldn't the best approach be not to ask for an email at all (or only optionally for receipt)?

Re: The "email is authentication" pattern

#346

We run a pretty unserious business. That is, our users use our accounts only out of convenience. The system we've settled on is this: 1. User enters email 2. We send a verification code to their email 3. User enters code, is signed in "indefinitely" (very, very long cookie) Whether or not they had an account before hand is irrelevant, we just register a new account if the email is new. The occasional user has multipl…

I run a small B2C app. Users sign up with their email address only, a password field isn't even present. This creates the account and logs in the user "indefinitely" on this device. If they ever need to login on another device, they can request a new password. This way, this removes a) signup friction und b) weak passwords, because most people never need to login on another device anyways.

Re: The "email is authentication" pattern

#348
post #120
post #3

Email accounts are the highest common denominator in online authentication. Phones are competitive, but people lose phones. Phone numbers are more common and durable, but the security of phone numbers is leagues below that of a flagship provider email account. It makes sense that so many authentication flows work this way. When designing a "fantasy football" alternate authentication system for the Internet, start wit…

> If the answer is "they just don't get access anymore" or "a panel of their peers attests to them", your fantasy authentication system also needs a fantasy species of sentient beings to serve as users, because it won't work for humans. This has been my single biggest argument against blockchain/cryptocurrency stuff for years: the "lose your key, lose your wallet" thing is fundamentally incompatible with real users.…

If you accidentally burn cash you cannot recover it. The paper in your hand isn't replicated in another place.

Humans have been unable to recover from mistakes since day zero

Re: The "email is authentication" pattern

#349
post #120

Earlier quoted context omitted.

> If the answer is "they just don't get access anymore" or "a panel of their peers attests to them", your fantasy authentication system also needs a fantasy species of sentient beings to serve as users, because it won't work for humans. This has been my single biggest argument against blockchain/cryptocurrency stuff for years: the "lose your key, lose your wallet" thing is fundamentally incompatible with real users.…

If you accidentally burn cash you cannot recover it. The paper in your hand isn't replicated in another place. Humans have been unable to recover from mistakes since day zero

For at least 12,000 years, humans have been getting very good at holding on to physical things.

Digital things, not so much. I'm a professional in the field, yet I've lost digital data in the past few years. Normal users who work in other fields? Lost cause.

Re: The "email is authentication" pattern

#350

Earlier quoted context omitted.

Government provided digital IDs would solve a lot of this. Yes, they may have their own problems, but outsourcing the action of identifying individuals to the government seems valuable and less prone to "lock outs" like Google and friends.

My wife works in a city clerk's office. They provide (among other things) vital records services for the city. Like getting birth certificates. To get a birth certificate, you must provide government photo ID with a name matching that of one of the names on the certificate you're trying to get . So you can get your own, or your child's, but not some random other person's. Lots of people were born before RealID driver…

[deleted]
Post reply on HN