Why don’t we do email verification in reverse?

> Magic Links mean that if there is any issue with any of the email servers in the chain (which there often are), my ability to log in to the website may be delayed by 10, 20, maybe even 30 minutes.

This same exact thing happens with a username and password driven site because almost all sites (rightfully) require you to confirm your account after sign up by clicking a link in your email.

I think this is the big one. On iOS, I don’t think most non-technical users know how to switch their default mobile Mail client if they use another alternative like Gmail or Outlook.

Do you think youre going to get scammed and send a fraudulent Western Union transfer? What do you think the venn diagram overlap between "uses a specific email for each service" and "gets phished" is? The people that even have the capacity to do the first aren't going to fall into the second. If someone is sending fraudelent transfers to scammers, they're not going to be smart enough to create multiple emails.

That’s what I used to believe. Circa 2000 the advice was ‘do what Yahoo! does’ and that was good, but when I revisited that in 2006 I found that Yahoo’s signup and login process was deformed by the need to discourage users from responding to phishing attempts —- a bank needs to be concerned about this but it will hurt the login for other sites that have higher iq users and aren’t big enough that spamming everybody is a good tactic.

I worked on one site (a chat service for Brazil) that had a 20% success rate for the login flow at first that we got up to the high 80s by tweaking this and that. Later I worked on one aimed at scientists that was in the low 80s before optimization.

Some tweaks from a long time ago are:

1. Put something like ‘we sent a message to your.email@somewhere.net‘ on the post-registration form where they are likely to see it if they make a mistake. Today forms are likely to ask for your email twice to catch this, annoying as it is.

2. Put a form field for the registration code on that form, we found that oriented people towards looking for a registration code. We still sent a link to click on but we found that users preferred to type the code into the form which was fine with us because they succeeeded.

3. Always store the current URL that the person clicked ‘register’ on and store it in the database so they end up where they started after the process is complete.

Guys,it's 2022! You shouldn't be requires to give out your email right along for verifying anything. Please allow the old dog to die.

Site generated communication should be entirely optional, and even then why not support signal,whatsapp, slack,discord,etc... (as a library of course).

Fight spam? Use captchas.

What I found out is email registration is very difficult without a phone number which in turn requires a government ID in most places. So email verification has become a lazy way to require govenment IDs for even the most basic sites.

It is all built around user hostility. I have added items to a cart,tried to check out and then decided to cancel the whole thing because they have no guest(no-email) check out and require email registration several times this year. Why would they not just take my money? My payment itself is verficiation of anything email can verify?

It is so stupid! Imagine being asked for your phone number and then they call your phone to verify it at every store or business you went to in person.

I challenge any commercial site owner to prove that email registration improves their botrom line.

For non-commercial sites, please understand that you are being needlessly hostile to your visitors, use federated authentication and provide a no-email registration path.

Personally, I think registration itself is outdated. You want users to buy something or generate content on your site. You can still call it registration if you want but you don't need to do more than the bare minimum of authentication which when federated can mean not storing anything new or special about the user other than their login session and associate their content with the identities associated with that session. For example, if HN with github federated, this post and my submissions would be under my GH identity in HN's db, if I want to setup a HN profile, that too would be under that identity. Unless you have a specific need for it, there wouldn't be a table of users with my identity in it.

Lastly, for those that use email as part of an authentication workflow: understand that the use's email security is now your responsibility, because even though you transfered risk lack of options means you are responsible for mandating email as point of failure. So if a user gets phished and damage is done on your site, your site is liable unless you are also providing email security training. There is a reason secret questions exist (although I don't like them), you are not suppose to allow control over an email account as the only factor of authentication requires to reset login credentials. The whole 2FA setup is meaningless if you do that.