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.
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.
This is an absurd position, and potentially illegal - for paid services.
You have a business relationship between the company and a person. Whether that person remembers the password or not is immaterial to whether they have the legal right to anything they purchased in the app.
> 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.
* 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)
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.
> And people who don’t want to share their email can use a temp email service, so it’s no skin off their back.
That seems to be a better option for bots than for actual users: if you care about the account, you probably would not want to make its password resettable via a service like that. Or even via a regular email provider you do not trust, and those could easily be the only kind available.
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.
Without traceability, any app that can be used for abuse will be. (An HN reader used an anonymous mail service to send me some hate speech and tell me to kill myself within the last day. The service they used to do it obviously does not care, but also cannot do anything about it, because they don't know who used their service to do it.)
Weird that no one said this yet: To verify users' legitimacy. If you make effort to block 10 minute email services it works kinda well and slows down bots
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.
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.
>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.