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.
Tough beans?
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.
Bots have no trouble signing up with @mybotfarm.example addresses.
* 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
/s?
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.
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.
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.
> 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
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?".
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.
But let's be real - nobody actually does that.
LOL WUT??
This is also ideal in “war dialling” eMail servers to get accurate lists of what eMail accounts exist on said server. This has been the case since marketing first hit the Internet.
Do you really want all of your legitimate eMail addresses to end up on spam lists? Because this is how you get complete and unabridged lists of your domain’s valid eMail addresses onto spam lists.
It’s why my own eMail server is set up to quietly confirm and accept any and all eMail sent to the domain - regardless of username employed. Even invalid eMail accounts get confirmed and incoming eMails to them get accepted.
Anything not sent to a valid account then drops into a catch-all account for further processing. Occasionally I’ll get eMail where the username was misspelled - it happens - and I just forward it to the appropriate family member.
The rest get reported as spam. And I enjoy making every last report. Enjoy ending up on a blacklist.
How can you avoid revealing the application through the `Origin` header?