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

51–60 of 151 posts

Re: Email verification protocol

#51

Post by Levitz »

immibis wrote: post #45
hombre_fatal wrote: post #25

Earlier quoted context omitted.

Most people want a way to recover their account if they lose those creds, especially when you ask them once they’ve lost their creds. It’s also a rudimentary PoW system against bots. And people who don’t want to share their email can use a temp email service, so it’s no skin off their back.

So make it optional. I've seen sites like that. Bots have no trouble signing up with @mybotfarm.example addresses.

Ultimately this is akin to password requirements. They are a bother but the average user is just much too careless to be trusted with their own security.

Re: Email verification protocol

#52

Post by ericpauley »

kogir wrote: post #22
ericpauley wrote: post #8

Hard to see how this provides substantial benefits over OIDC. Either one requires support from the email provider, but one is already standardized and has widespread support.

OIDC is usually limited to a small selection of providers.

This isn’t fundamental to its design, though. It’s a result of providers wanting to gate access to identities for various reasons. The protocol presented here does nothing to address this gating.

Re: Email verification protocol

#53

Post by gruez »

cxr wrote: post #50
gruez wrote: post #39

Earlier quoted context omitted.

>If instead of a username, an email address to register, that generally results in one less degree of freedom [...] It "generally" doesn't, because the average user isn't randomly generating usernames per-site, just like they're not randomly generating passwords per-site. If they're randomly generating usernames per site, they'll need some sort of system to keep track of it, which is 90% of the way to using a passwor…

To start with, randomly generated usernames weren't mentioned, and they are not a prerequisite. > It "generally" doesn't, because the average user isn't randomly generating usernames per-site What other people do, whether average users or not, doesn't matter. When average user Alice is registering accounts on Websites A and B, the fact that average user Bob doesn't use different usernames for his accounts doesn't cha…

>To start with, randomly generated usernames weren't mentioned, and they are not a prerequisite.

I've seen sites randomly generate passwords for users as well. Does that mean users reusing their passwords at all is a prerequisite? Moreover if we're really accepting "whether average users or not, doesn't matter", I can also say that using emails doesn't decrease security because you can use randomized emails, as others have mentioned. At some point you have to constrain yourself to realistic threat models, otherwise the conversation gets mired in lawyering over increasingly implausible scenarios. For instance, by asking for emails at registration, you can more easily perform 2fa, whereas you can't do that with only a username/password combination[1].

[1] before you jump to say "but can ask for an email with username/password too!", keep in mind the original claim that username/password is better was in response to a comment asking "Why must apps require email?".

Re: Email verification protocol

#54

Post by cxr »

gruez wrote: post #53
cxr wrote: post #50

Earlier quoted context omitted.

To start with, randomly generated usernames weren't mentioned, and they are not a prerequisite. > It "generally" doesn't, because the average user isn't randomly generating usernames per-site What other people do, whether average users or not, doesn't matter. When average user Alice is registering accounts on Websites A and B, the fact that average user Bob doesn't use different usernames for his accounts doesn't cha…

>To start with, randomly generated usernames weren't mentioned, and they are not a prerequisite. I've seen sites randomly generate passwords for users as well. Does that mean users reusing their passwords at all is a prerequisite? Moreover if we're really accepting "whether average users or not, doesn't matter", I can also say that using emails doesn't decrease security because you can use randomized emails, as other…

> I've seen sites randomly generate passwords for users as well. Does that mean users reusing their passwords at all is a prerequisite?

What?

> I can also say that using emails doesn't decrease security because you can[*] use randomized emails

That _doesn't_ _matter_. Viz:

> The only thing that matters is what they're doing—and whether what they're doing increases or decreases risk.

Re: Email verification protocol

#55

Post by thedelanyo »

charles_f wrote: post #47
tytho wrote: post #14

Earlier quoted context omitted.

Many applications need a way to contact a user (security breach, password reset). If one only has a username and forgets the password, there’s no way to reverify the user.

You don't need to validate email for that.

I think if you're not verifying emails, you'll also receive lots of bot signups.

Re: Email verification protocol

#56

Post by gethly »

kogir wrote: post #22
ericpauley wrote: post #8

Hard to see how this provides substantial benefits over OIDC. Either one requires support from the email provider, but one is already standardized and has widespread support.

OIDC is usually limited to a small selection of providers.

Well the problem is simply user base. There is no point in being provider if you have 100 users. On the other hand, despite OIDC being standardised, there are way too many ways of implementing it. It is essentially impossible to have a "wildcard" support for OIDC providers. How do I know? I just implemented one myself. For example, providers usually support only one or very few authorisation flows, so in reality you would likely end up with a lot of failed attempts to sign up with some "3rd world" provider.

PS: just take PKCE where the provider has no way of communicating whether it is supported, or required, at all.

Re: Email verification protocol

#57

Post by hypeatei »

Arch-TK wrote: post #46

Cool, so if I want to use myname+yourdomainname.here@myemail.com to register on your application I now first have to go to some third party(?*) to verify that myname+yourdomainname.here@myemail.com is valid**. And then, once I've gone through the hassle of that, I have to go back to your website to use the third party service to verify my email. Thanks I guess... * It's not clear if this service would be provided by…

What is your first paragraph referring to? This whole standard is trying to eliminate the context switching that happens when a website wants to verify your email.

Perhaps you mistook the two bullet points outlining what currently happens as goals for the standard?

Re: Email verification protocol

#58

Post by nine_k »

immibis wrote: post #44
phyzome wrote: post #31

I don't know if this is the solution, but we desperately need one. It's to the point where "email bombing" is forcing service providers to add captchas to login and registration because those forms are being abused as mail-flooders.

They could consider not using email at all

Any open channel that can be read by a human that could be lucratively scammed will be used the same way.

Re: Email verification protocol

#59

Post by jauntywundrkind »

I am a little sad the original pretty interesting FedCM work got reduced to this. There was some neat work underway to allow using identity providers without the site even knowing the provider! https://github.com/w3c-fedid/FedCM/issues/677

But after some work the team scoped down, to focusing on email verification. I think that's what lead to this spec? https://groups.google.com/a/chromium.org/g/blink-dev/c/rwu9w...

Re: Email verification protocol

#60

Post by nine_k »

This is sort of missing the point of email verification. It's to test that the email from this particular site is deliverable and visible to the user, not just that it's a legitimate address known to work by some third party.

A user may make a typo in the email, and that email might still be a valid email know to work (but for another, unrelated person). The user's email agent (such as GMail or Outlook) can mark the email unimportant and make it hard to notice, or even mark as spam. All these issues are much better to find out and iron out before the user sees themself unable to communicate, or successfully bound to an email they cannot access.

The whole point of email verification is to make certain that a channel of alternative communication exists for a case when the user would be unable to identify themself normally, for whatever reason. A working email alone is not always sufficient for successful credentials reset, but almost always it's much easier to when the user has it.

Post reply on HN