Or, like I wrote on the Go+ community back in 2014, and what Microsoft does, you don't have to remember a password, but every time you have to log in a "password" mail is sent.
So the verification process isn't necessary anymore.
Why don’t we do email verification in reverse?
151–160 of 329 posts
Re: Why don’t we do email verification in reverse?
#152Earlier quoted context omitted.
You can solve this problem without a signup form. Just give the user two links: sign up and log in. Both ask for email address first. The next screen tells them to check their email. You can use unusual flows without confusing users as long as you give them cues about how to do what they're trying to do.
That doesn’t solve the issue of passwordless login, though, which is the fact not everyone has access to their email on every device at all times. Need to check something attached to a work email (hello Slack) but purposefully not got work email set up on your personal device? Good luck
It's not only having "access to your emails", sometimes these services will send links that are supposed to open in an app and do something there.
... and it just doesn't work.
Re: Why don’t we do email verification in reverse?
#153We’re (fx.gl) using it in all our games to create a connection between game account and email. It works great. User click on mail to link. Send email with uniq token. Sever receives email and connection is created.
Some caveats:
1. not everyone has email set up on phone. We provide instructions to send email by hand.
2. We emphasize for user to choose correct email if they using work and personal email. No good solution here if user connect game account to work email. Only letter to support
Re: Why don’t we do email verification in reverse?
#154The ‘mailto:’ thing is a dealbreaker.
A _significant_ amount of users, especially non-technical ones, won’t have a properly configured email client. They’ll click signup, it’ll open Outlook or Apple Mail, and then they’ll give up on your app in frustration because they can’t register.
There’s very limited room for shifting the signup paradigm in a way that won’t leave N% of your potential users unable to sign up.
Re: Why don’t we do email verification in reverse?
#155Earlier quoted context omitted.
You can solve this problem without a signup form. Just give the user two links: sign up and log in. Both ask for email address first. The next screen tells them to check their email. You can use unusual flows without confusing users as long as you give them cues about how to do what they're trying to do.
That doesn’t solve the issue of passwordless login, though, which is the fact not everyone has access to their email on every device at all times. Need to check something attached to a work email (hello Slack) but purposefully not got work email set up on your personal device? Good luck
Want to log in on your TV?
Ha. Good luck with that. Your email provider probably only supports Chrome.
Re: Why don’t we do email verification in reverse?
#156Earlier quoted context omitted.
Unpopular take: users should be free to use bad and insecure passwords for services they don't care about.
Unfortunately even privileged users (that have authority to change the permissions or possibly passwords of other users) can still use weak passwords. A better solution would be to have your browser prevent you from reusing passwords (it only needs to keep hashes).
If the web browser is governing the passwords you can and can't have, and forcing you to have unmemorisable passwords, you're better off rethinking the whole thing. For instance, it probably makes more sense to ask the web browser to generate keypairs rather than passwords if we know the passwords cannot possibly be memorised.
Re: Why don’t we do email verification in reverse?
#157Earlier quoted context omitted.
I do and tell people to do the same. Unfortunately we can't force people to actually do it.
Firefox is great in that regard: when you fill in a signup form it will automatically suggest you a long, generated password, and will then store it for you.
That is not really unique to Firefox, right? Safari does it as well and I am pretty sure Chrome does it too (I am not a Chrome user, so I can't check).
Re: Why don’t we do email verification in reverse?
#158This suggestion makes things worse.
If you make a service and ask for email validation, you want validation that the user has that email address. Since anyone can spoof e-mails from any address, getting an email from the address is not validation for anything.
You need to send an email to the account and get a response to validate the email address is real. Otherwise it's trivial for me to go to any web site and pose as you. All I would need to do is spoof your email address.
Edit: I agree that the current state of affairs is unsatisfactory :-)
Re: Why don’t we do email verification in reverse?
#159Earlier quoted context omitted.
Yeah I don’t get it. Is this the reasoning? Email is slow to get to me I use neomutt (there are dozens of us, dozens!) and so links sometimes are wonky. So let’s use SPF and DMARC, something totally outside of a regular email user’s control, to do this task. And hope that it works.
> I use neomutt (there are dozens of us, dozens!) and so links sometimes are wonky. I used neomutt for that one example, but the other error modes happen to me regularly on macOS with the system mail client. For example, I regularly (~1/week) run into services that expect the verification email to be opened in the same browsing session, but Chrome "helpfully" picks a different profile. (The point about neomutt was no…
In my experience, many developers are unaware of multipart email. Most are unaware of MIME or dismiss it as obvious, old and unnecessary.
Re: Why don’t we do email verification in reverse?
#160I like that there's still options out there around authentication that I haven't seen before but this method is hostile towards folks without a dedicated email client. Personally I only ever login through web mail and have no client so `mailto` isn't a shortcut.
I still think magic links are a good compromise. With a user / pass you still need to verify your email as a separate step. A magic link sends you an email and you're technically verifying your email every time you use it, so it removes an extra step.
It's also really useful for being able to login from multiple devices without needing to keep your password synced with a multi-device password manager. That's especially handy on mobile because even if you're around your desktop with your password manager who the heck wants to manually type `pm'TWZS"$G39c(Es:k@v3-*IhP#DUbows:=='"Z],Ud"R8XO` as a password into your mobile phone?
Lastly, it lets you put the burden of MFA on your email account. If your email account is protected by MFA then your app using magic links is protected by MFA. It means users don't need to give out their phone number or hook up another site to their authenticator app.
I really don't understand why so many folks hate magic links. They solve a number of problems in a pretty reasonable way at the cost of having to wait 5 seconds for 1 email to verify your email at which point the site can set a cookie for a year and you don't have to deal with logging in by email for another year.
You can also protect sensitive actions by requiring folks to verify their email to replicate how a site might ask for your password to do something like change billing details or whatever makes sense for your app.