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

Email verification protocol

github.com

Post reply on HN
Print view View original

101–110 of 151 posts

Re: Email verification protocol

#101

Post by minitech »

0x073 wrote: post #91

Make everything what works complicated. There is no advantage. "User privacy is enhanced as the issuer does not learn which web application is making the request as the request is mediated by the browser." Every web application nowadays send you a welcome, onboarding, reminder after the verification. (No user privacy enhancement) So we get a new process that solves nothing, but makes everything complicated. (And comp…

The convenience advantage is significant, and it goes farther than convenience, since it’s very common for services to have their verification mail blocked or sent to spam. (Bonus pain: there’s no user-visible difference between delayed and blocked mail.)

The privacy advantage is also significant and real: no, not every web app sends an onboarding reminder, and the current state of web apps came to be without this functionality, so you can expect behaviour changes for those services that value the privacy, plus new services/authentication options to spring up that weren’t previously possible.

Re: Email verification protocol

#102

Post by blm126 »

thayne wrote: post #82
kbaker wrote: post #74

Earlier quoted context omitted.

But not every email provider would support this new (from scratch) protocol either? Just don't see the need to reinvent OAuth but with a reduced scope for just email validation. Just add a happy path for this into OAuth itself?

One other problem is there isn't a way to definitely know that a given OIDC provider is authoritive for a given email. Although, this spec could probably be simplified by just having a dns record that specifies the domain to use for oidc for emails on that domain. Another is that there is a lot of variance in OIDC and OAuth implementations, so getting login to work with any arbitrary identity provider is quite diffic…

I wouldn't mix OAuth and OIDC up when thinking about this. OAuth is a chaotic ecosystem, but OIDC is fairly well standardized.

OIDC actually does have a discovery mechanism standardized to convert an email address into an authoritative issuer. Then, it has a dynamic registration mechanism standardized so that an application could register to new issuers automatically. Those standards could absolutely be improved, but they already exist.

The problem is that no one that mattered implemented them.

If you want to get anywhere with something like this, you need buy-in from the big email providers(Google, Microsoft, Yahoo, and Apple) and the big enterprise single sign on providers(Ping, OneIdentity, and Okta). All of those companies already do OIDC fairly well. If they wanted this feature to exist, it already would.

Instead, it seems like big tech is all-in on passkeys instead of fixing single sign on.

Re: Email verification protocol

#103

Post by brody_hamer »

thayne wrote: post #82
kbaker wrote: post #74

Earlier quoted context omitted.

But not every email provider would support this new (from scratch) protocol either? Just don't see the need to reinvent OAuth but with a reduced scope for just email validation. Just add a happy path for this into OAuth itself?

One other problem is there isn't a way to definitely know that a given OIDC provider is authoritive for a given email. Although, this spec could probably be simplified by just having a dns record that specifies the domain to use for oidc for emails on that domain. Another is that there is a lot of variance in OIDC and OAuth implementations, so getting login to work with any arbitrary identity provider is quite diffic…

> a dns record that specifies the domain to use for oidc for emails on that domain.

Oooh I like this idea!

Re: Email verification protocol

#104

Post by TZubiri »

0x073 wrote: post #91

Make everything what works complicated. There is no advantage. "User privacy is enhanced as the issuer does not learn which web application is making the request as the request is mediated by the browser." Every web application nowadays send you a welcome, onboarding, reminder after the verification. (No user privacy enhancement) So we get a new process that solves nothing, but makes everything complicated. (And comp…

I thought this initially, the privacy thing looks like a non issue and is confusing. But the advantage is stated in the preceding paragraph. The user doesn't need to leave the signup flow and doesn't need to open their email.

The auth mechanism flows through the cookies, assuming the email provider offers a web browser and the user is signed in this could be seamless, although I'm not certain the cookie could be safely read cross site without risk or without being blocked by the browse

It wouldn't be simple to implement but not impossible, and it sounds like it would cost nothing to the user, it could work behind the scenes. Like as a user you are logged in to gmail or zoho mail in your browser. You sihn up for another service and you didn't get a confirmation email, just a welcome email. No fucks are given, it just works.

Mobile does this with autofilling auth codes sometimes with sms, so there's precedent.

Congrats OP the idea looks feasible. I'm usually the ackshually guy looking for the nitpick, but it looks nice. Will check the technicals later, cause the devil is in the details.

Re: Email verification protocol

#105

Post by TZubiri »

hypeatei wrote: post #62

The ideas proposed in here aren't bad, but it does seem like you'll need to maintain two user flows as a site owner because: 1) Not all email providers will implement this, and 2) Users may not be signed into their email at the moment they signup As a developer, I would find it easier to have one "verification code" flow for all users rather than fragmenting the process; it's much easier to document for your support…

Of course, if the new standard which no one supports doesn't work, the incumbent standard would be used.

Re: Email verification protocol

#106

Post by TZubiri »

notepad0x90 wrote: post #95

I have a couple of problems with this, although kudos for the author and I won't dismiss this project's usefulness or value. 1) Email shouldn't be used for this purpose. It is inherently insecure. Many have tried, you won't succeed. 2) The subject line of the email should not contain verification details (code), it shouldn't even imply the content of the email. "A secure message from " is enough. 3) The device receiv…

1) Email shouldn't be used for this purpose. It is inherently insecure. Many have tried, you won't succeed.

Sorry if I didn't read the rest. But email isn't secure? Email isn't used for auth? First I've heard of such a thing

Re: Email verification protocol

#107

Post by TZubiri »

thayne wrote: post #72
kbaker wrote: post #63

Earlier quoted context omitted.

Why is the solution not OAuth/OIDC? Or maybe creating some sort of reduced OAuth "Anonymous-Site-Verifying-Your-Email-Exists" flow?

Not everyone uses an email provider that is also also an OIDC provider.

Additionally, some corporate or personal policies might prefer to NEVER use SSO, even if it is sometimes accepted. I hate being presented with option to login with email or login with Google, and I don't know which I signed up with.

God forbid I accidentally make an account with SSO and another with email but the same email. I'd rather just always use email, it's supposed to be a convenience, the advantages are lost when it goes south once

Re: Email verification protocol

#108

Post by TZubiri »

kbaker wrote: post #74
thayne wrote: post #72

Earlier quoted context omitted.

Not everyone uses an email provider that is also also an OIDC provider.

But not every email provider would support this new (from scratch) protocol either? Just don't see the need to reinvent OAuth but with a reduced scope for just email validation. Just add a happy path for this into OAuth itself?

It's more of an invisible feature than a protocol.

The signup protocol and user flow is the same if the feature is supported or not. You just skip a step if the convenience feature is supported.

With SSO the user is inconvenienced with an additional option at sign up and login, and there's the risk of duplicate accounts. Also stronger vendor lock in.

Re: Email verification protocol

#109

Post by notepad0x90 »

TZubiri wrote: post #106
notepad0x90 wrote: post #95

I have a couple of problems with this, although kudos for the author and I won't dismiss this project's usefulness or value. 1) Email shouldn't be used for this purpose. It is inherently insecure. Many have tried, you won't succeed. 2) The subject line of the email should not contain verification details (code), it shouldn't even imply the content of the email. "A secure message from " is enough. 3) The device receiv…

1) Email shouldn't be used for this purpose. It is inherently insecure. Many have tried, you won't succeed. Sorry if I didn't read the rest. But email isn't secure? Email isn't used for auth? First I've heard of such a thing

> Email isn't used for auth?

I didn't say that, you added that part. It is used for auth. it isn't secure.

Email is less secure than SMS, unless you encrypt your email (even then..). With email, there are multiple middle parties that can just read the message. Forget malicious insiders, it is more than reasonable to assume at least one MTA out there is compromised. Mail server CVE's aren't that rare.

Furthermore, despite email being used for auth, as you correctly claimed, email clients aren't secured like authentication applications or password managers are. For most people, a compromise of their email account means a compromise of most of their other accounts.

Even furthermore, not only is email used for authentication, email is being used to revoke,reset and tamper with other authentication methods and account security in general. You don't just login to apps via email, your password, MFA, account changes,etc.. can all be done by someone controlling your email (and more and more, your phone number/SIM these days).

End to end encryption is all the rage on sites like HN, but I'm shocked when those same people have no problem using email for sensitive operations.

Re: Email verification protocol

#110

Post by 8organicbits »

Is there a nonce relay vulnerability here? You try to verify your email with site A. Site A starts an email verification with site B. Site B sends a nonce to A, A relays the nonce to the user. The user generates the proof, sends it to A. Then A sends it to B.
Post reply on HN