Live data from Hacker News

Email verification protocol

github.com

41–50 of 151 posts

Re: Email verification protocol

#41

This is sorta interesting, but it fails on several levels. First, email verification as it exists currently is fairly simple, there are a lot of different ways to do it, and it works universally for all email addresses (as long as you don't expire codes too fast for servers that use greylisting). This protocol solves a pretty contrived problem ("By sending the email verification code, the inbox provider knows the use…

If my memory serves, this is the same wolf in sheep’s clothing that the attestation based Web Environment API was, from the same kinds of very interested parties. (Edit: I may be misremembering the name of that proposed API.)

It’s not about efficient, effective solutions. It’s about control. Something you have to look at with WICG and W3C is the source of proposals and drafts.

Re: Email verification protocol

#43

Earlier quoted context omitted.

A good user experience does its best to avoid tough beans. That's kind of UX 101.

In the case of security procedures, I'd argue that there is some room for tough beans. Reducing security to cater for carelessness seems like a really bad compromise to me, one that I see far too often.

[deleted]

Re: Email verification protocol

#44
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

Re: Email verification protocol

#45
post #10

Why must apps require email? Why not only username and password?

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.

Re: Email verification protocol

#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 a third party (in which case, the problem has merely just been moved) or the email provider. It sounds like the former, but in case it's the latter, then this doesn't have as big an impact I guess.

** While _I_ as the owner of an email address can decisively know that all emails of the form `myname+@myemail.com` will go to me, you as the owner of a website attempting to verify my email cannot know that. The standards specify that + is valid in an email user part, but they do not require plus addressing to work.

Re: Email verification protocol

#47
post #14
post #10

Why must apps require email? Why not only username and password?

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.

Re: Email verification protocol

#48
post #14
post #10

Why must apps require email? Why not only username and password?

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.

There are many ways to re-verify the user if one forgets a password. Some may even be more secure than sending a e-mail. Simplest is a set of single-use reset codes that could be generated at signup or later on, like the ones to remove 2FA.

Re: Email verification protocol

#49
post #10

Why must apps require email? Why not only username and password?

* recover password

* prevent signing up for someone else (validate it is you who owns the email)

* poor man's mfa, although please allow me to use totp instead (probably the three most legitimate reasons from a user perspective, email validation prevent you from making a typo)

* send ads and notifications (legitimate from the provider's perspective, they want campaigns to succeed, email validation makes them sure emails land)

* reduce throw-away or bot accounts

Re: Email verification protocol

#50
post #39
post #36

Earlier quoted context omitted.

Credential stuffing happens when a user signs up on one Website B with account information matching the information they used when setting up their account on Website A, and the operator of either Website A or Website B can use those credentials to access the user's account with the other operator. If websites authenticate with username and password combo chosen by the user, then credential stuffing is neutralized if…

>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 change the fact that if Alice would have otherwise registered account agirl on one site and pie_maker26 on the other, but instead has been forced to enter her email address, then that has a non-zero effect on risk.

For the claim as stated to be untrue, the difference in risk would need to be zero.* But it isn't zero. The claim as stated is true.

> For it to practically make a difference, you'd need someone who cares about […]

That's not true. Users who are exposed to lower risk by accident are still exposed to lower risk. It's not a prerequisite for the user to care at all, nor does it require them to understand any of this or to be trying to adhere to any particular scheme to achieve a certain outcome. The only thing that matters is what they're doing—and whether what they're doing increases or decreases risk. Intent doesn't matter.

* or it would need to be somehow less risky when email addresses are required in place of where a username otherwise would be, but that's not the case, either

Post reply on HN