Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The "email is authentication" pattern

rubenerd.com

Post reply on HN
Print view View original

91–100 of 474 posts

Re: The "email is authentication" pattern

#91

Post by layer8 »

dogcomplex wrote: post #21

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…

Because it’s still quicker or more convenient to use a password if you remember it or use a password manager.

Re: The "email is authentication" pattern

#92

Post by arnaudsm »

echoangle wrote: post #73
stavros wrote: post #66

Earlier quoted context omitted.

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.

Can you elaborate on „email sending isn’t free“? What are you using to host the webapp? Can’t you just set up your own mail server and send whatever you want?

I worked on email delivery systems. Your comment makes me realize that something that was free and trivial in the 90s is now painfully complex and expensive, because of monopolistic practices and spammers. We ruined something great.

Re: The "email is authentication" pattern

#93

Post by throwaway237289 »

candiddevmike wrote: post #29
tptacek wrote: 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…

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.

[flagged]

Re: The "email is authentication" pattern

#94

Post by eaglemfo »

candiddevmike wrote: post #29
tptacek wrote: 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…

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.

Wasn't there a recent sidechannel attack on Infineon cryptography chips? The EU passports likely use the Infineon chips.

Re: The "email is authentication" pattern

#95

Post by kjellsbells »

efitz wrote: post #36
nfw2 wrote: post #30

Earlier quoted context omitted.

Can you expand what you mean when you say the security of phone numbers is leagues below email? If someone can gain access to someone's phone, it seems like they would gain access to their email as well.

Mobile phones identify themselves to the mobile network through a number called the IMEI. IMEI cloning is not particularly difficult nor does it require exotic equipment. This means that it is relatively easy for an attacker to be able to spoof your phone to a mobile network, for example, to receive SMS messages with one time passwords. Cloning your IMEI has nothing to do with the data that is on your phone, so if so…

IMEI or IMSI? I think it is the subscriber identity that is on the SIM that needs to be cloned, not the hardware identifier of the device (ie its the IMSI that matters, not the IMEI).

SIMs and SIM burners can be purchased trivially on the open market, and cloned without too much difficulty. Although, a social engineering attack on the employee at the cellphone store is a superior method since it automatically gives you a "known good" SIM with the operator's keys, etc.

Re: The "email is authentication" pattern

#96

Post by eaglemfo »

aucisson_masque wrote: post #72
candiddevmike wrote: post #29

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.

> Government provided digital IDs Oh man, that sounds like a terrible idea privacy wise. Every website would make use of it to track it's user.

The german gov ids actually have a way to issue pseudonymous tokens where websites can only see that you are the same person as last time. You can't make 2 accounts on the same site if sich things are unwanted. You can't link accounts across providers.

How it works under the hood? No specific idea. I wonder if its sound.

Re: The "email is authentication" pattern

#97

Post by miki123211 »

I'm surprised we don't have a standardized, cross-browser, simple, email-based authentication system.

Basically something like this:

1. Website generates random string as challenge, sends to Browser, invokes API via JS on the client side.

2. Browser asks user to select the email to use, allows adding a new one.

3. Browser sends its auth token and challenge string to Browser Maker, Browser Maker verifies that the auth string is valid, signs email address and challenge with its public key, transmits signature back to Browser.

4. Browser sends data back to Website, Website verifies that the signature matches and that Vendor is trusted, lets user in.

As an extra precaution against Vendor being hacked, Email providers could implement support for the system. Compliant providers would handle the email verification flow themselves, informing Browser maker when done and sending an extra certificate. Websites would then refuse to accept any logins where Email Provider indicated support (via DNS records) but its certificate wasn't included.

This would also make the system usable in small (and therefore untrusted) browsers, as long as the email provider implemented support.

It would even improve privacy, Browser Maker and Email Provider would only ever see the random challenge string, which would make it impossible to track the websites you visit.

THe idea isn't hard to implement, we've had the tech to do it since the 90's (US restrictions on crypto notwithstanding). What we have instead is a mess of passwords that nobody can remember and proprietary authentication flows with horrible developer experience, terrible privacy issues and spotty website support.

Re: The "email is authentication" pattern

#98

Post by dilyevsky »

candiddevmike wrote: post #29
tptacek wrote: 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…

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.

ID.me kinda already does this. They integrate with IRS, SSA and bunch of local government stuff

Re: The "email is authentication" pattern

#99

Post by iknowstuff »

JumpCrisscross wrote: post #40
candiddevmike wrote: post #29

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.

> Government provided digital IDs would solve a lot of this A lot of what? It seems like the worst of all worlds, given that ID would not only unlock some highly sensitive things, but also be difficult to change and tremendously revealing.

Nah the government could just give a website a unique id per real user per website, without revealing who the user is. Merely verifying that they are the same person as last time.

Re: The "email is authentication" pattern

#100

Post by klabb3 »

byteflip wrote: post #61
dogcomplex wrote: post #21

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'm coding up a webapp with this exact login process - the issue I've found is on mobile phones - apps like gmail won't let you copy the link into a browser without a preview. The preview consumes the link. (next.js auth) It's a bit annoying, since I don't want to login into the gmail in-app browser, I want to login on my regular browser.

Yes easy mistake to make. But this goes back to HTTP basics: a GET request shouldn’t mutate state. Either don’t consume the link (ie allow reuse), have a user confirm action with POST, send a code instead. There are many alternatives.

Personal favorite? Send a 6-digit code with ~1h expiry, exchange for a refresh token and keep the session for a long time. If you have really high value irreversible actions then you can just confirm with a new code.

Also works if mail client is on a different device.

Post reply on HN