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.
Email verification protocol
31–40 of 151 posts
Re: Email verification protocol
#32why does it have to be email?
Re: Email verification protocol
#33On the rare occasions where I would care about this as a user, I make a throwaway account on an anonymous service. If I don't want my email service to know I have an account with you then I don't trust you to handle my main address either.
Re: Email verification protocol
#34Earlier quoted context omitted.
I agree. username and password is much more robust to credential stuffing attacks.
> username and password is much more robust to credential stuffing attacks. /s?
In theory, maybe to some extent yes - unique usernames could beat reused emails.
But let's be real - nobody actually does that.
Re: Email verification protocol
#35Earlier quoted context omitted.
> username and password is much more robust to credential stuffing attacks. /s?
tell me how it's not.
The onus is on you here… but, I think I know where you’re going with this. In terms of number of email addresses people have and use, vs number of usernames people have and use, you might be right that some people have 1 or 2 email addresses and many usernames.
Email masking has become easier to use, and many people use `+addressing` to uniquely tie their email to the service for spam prevention / tracking, which would make stuffing harder.
In these cases, email would be much more unique and a better protection against stuffing. HOWEVER, it’s not obvious how Email verification protocol would work for these types of things.
Re: Email verification protocol
#36Earlier quoted context omitted.
tell me how it's not.
You're the one who made the claim. So please explain how it is .
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 the user avoids re-using the same combo, effected by the user selecting at least one of a different password or the selection of a different username.
If instead of a username, an email address is required to register, that generally results in one less degree of freedom; rather than being able to create a username with Website B that differs from the username they created on Website A, absent the use of a wildcard/catch-all mailbox or forwarding service (which are not straightforward to set up, and almost nobody has one), the user is required to disclose an existing email address.
(It also increases the surface area for attacks, since the malicious website, now knowing the user's email address, can attempt credential stuffing with the user's email provider itself.)
You can balk at whether or not these are negligible differences, but it's non-zero. Therefore, all other things held equal, then strictly speaking it is more robust.
Re: Email verification protocol
#37> 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. How can you avoid revealing the application through the `Origin` header?
The request is sent by the browser, not the webapp itself (ie. using xhr or fetch) so it doesn't have headers like "Origin" added.
Ha! Thank you, I misunderstood who was behind this proposal but since it's W3C it's something that would directly be implemented by the browser itself.
Re: Email verification protocol
#38Why 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.
> Many applications need a way to contact a user … password reset
At this point the password is pointless, you might as well just use the email address. Or perhaps a distinct username and email address, but then there would probably be a “forgot username” workflow making that as pointless as the separate password.
Re: Email verification protocol
#39Earlier quoted context omitted.
You're the one who made the claim. So please explain how it is .
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 password manager (and therefore randomized passwords, immune to credential stuffing). For it to practically make a difference, you'd need someone who cares about security enough to randomize usernames, but for whatever reason doesn't care enough about security to randomize passwords.
Re: Email verification protocol
#40Earlier quoted context omitted.
> If one only has a username and forgets the password, there’s no way to reverify the user. Tough beans?
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.