This would cause so many issues in a time when most users use webmail. The magic link in email works, why change it for 0.001% of you users who happen to use a command based email program.
Why don’t we do email verification in reverse?
221–230 of 329 posts
Re: Why don’t we do email verification in reverse?
#222The whole point of email verification is to verify that the user is able to receive email at the given address. Aside from the other issues mentioned here, the proposed solution does not achieve this.
I can't think of anything I've signed up for that would care about the distinction personally, any examples?
I have *@kayode.co forwarded to kayode@kayode.co.
I can only send from kayode@kayode.co and only if I configured my mail client properly because my account is actually a fastmail.com address. Unconfigured, the mail client will send as the fastmail account.
Re: Why don’t we do email verification in reverse?
#223Earlier quoted context omitted.
I hate the email login link stuff, and any site that has it as the only option, I move on unless absolutely forced to use it. Especially a pain if I'm trying to login on a device without my email.
You don't need to have email on the device you are logging in from Can take out phone and click link
On at least half of those services, that ends up with me being logged in on my phone which is decidedly not what I want.
Plus I don't know who's using that to help adtech build their cross device mappings
Re: Why don’t we do email verification in reverse?
#224Earlier quoted context omitted.
> 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.
With magic links it happens every single login. Confirmation email only needs to be done once per email. I thought this was obvious? And most websites don’t require confirmation email to log in, they require it to unlock certain features.
> With magic links it happens every single login. Confirmation email only needs to be done once per email. I thought this was obvious?
You don't have to do it on every single login. Check my previous reply's comment:
> 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.
There's nothing "magic" about magic links and "remember me". You still read this information from a session and can optionally look up the details from an encrypted and signed cookie (or Redis / Memcached / whatever session back-end) with a user ID which then loads a user from your DB on the back-end. It's the same exact workflow as a user / pass strategy.
Re: Why don’t we do email verification in reverse?
#225Earlier quoted context omitted.
Password managers are a single point of huge vulnerability. Unless password managers have a bug bounty of 3m$, then it’s less than the assets I’m protecting with it. Also, Chrome itself is a password manager.
> Also, Chrome itself is a password manager. Until the day Google locks your Google Account.
This would only break sync and not access to existing passwords at least, unlike most Google services where you'd be totally SOL
Re: Why don’t we do email verification in reverse?
#226This is not well reasoned. Sending emails can be easily spoofed, because sending doesn't fully check the identity of the sender as being in control of the email account. There is discussion of various technologies like SPF or DKIM, but those are not universally applied. When they are applied, there isn't universal quality in their application. The crux of verification using an email account is that the person _contro…
> This is not well reasoned. Sending emails can be easily spoofed, because sending doesn't fully check the identity of the sender as being in control of the email account. There is discussion of various technologies like SPF or DKIM, but those are not universally applied. When they are applied, there isn't universal quality in their application. I bring up both of these at the end of the post, under "potential limita…
Got it!
Everyone should be able to express their thoughts.
Re: Why don’t we do email verification in reverse?
#227Earlier quoted context omitted.
Password managers are a single point of huge vulnerability. Unless password managers have a bug bounty of 3m$, then it’s less than the assets I’m protecting with it. Also, Chrome itself is a password manager.
It’s still better than using the same few passwords everywhere or having a system with the site name. Because you need only on website vulnerability, which is quite common, to compromise your passwords. It’s better to have a single unlikely point of failure than many guaranteed points of failure in my opinion. Chrome has a password manager but the key is stored for you, which is less secure because it’s not using a H…
Your single point will be compromised. Someone gets access to your system they now have access to all of your passwords. Your password manager is hacked. Your device dies. Putting your eggs in one basket feels like a smart thing until you lose that basket.
Re: Why don’t we do email verification in reverse?
#228I... don't particularly get it. He mentions spoofing, he writes a page about how spoofing works... but says a lot less about how it actually impacts his solution or how to fix it. Besides the fact that implementing a new security scheme means you have to think through every possible path and can be sure you're still missing a few, there are two major issues: - not everybody has SPF or DKIM, and definitely not everybo…
When opening for the first time, Gmail asks to be registered as the mailto handler, but I guess people just hit "no" not knowing what's that about. And there's probably a lot of web-based clients that didn't care to implement this, so yeah, if you want to use mailto links, you better have a big and patient customer support team at hand
Even if all web clients were perfect, and all users understood what a mailto handler is perfectly, wouldn't it still break if people have multiple email addresses? If you have a gmail and a mail from one of Microsoft's mail providers, you can only have one of those webmail pages as your default mailto handler, right?
Re: Why don’t we do email verification in reverse?
#229I don't understand why people complain about the mailto: option.
Whichever after or before, people will need to open up their mailbox to have access to their newly created account, no matter what, so it does not change anything.
The account creation page could easily provide a plain text email as an option, copy/paste the address, copy paste the code you've been given to send and off you go. Or it could provide both options. Link clicking and mailto.
Not great but else you can configure mailto:handling on any browser/OS
Re: Why don’t we do email verification in reverse?
#230At a high level, you have to validate what you need. If you don't need the user's email address, don't validate it. If you need an address the user can send from, validate that they can send from it. If you need an address they can receive at, validate that they can receive on it.
Beyond security problems, there can be all kinds of other failure modes. Maybe my domain is blocking email from you. Maybe the address I want to use can't send.
If you need the address because you'll be sending password resets and invoices to it, you want to validate that they can receive there. It was never about whether they "own an email account", whatever that means.