"fewer opportunities for the user to make mistakes" Really?
Yes. Please, learn from my fail.
Why don’t we do email verification in reverse?
11–20 of 329 posts
Re: Why don’t we do email verification in reverse?
#12I personally like the scheme. But I think it caters to the technologically capable, in particular the “compose an email with this bit of magically secure content” skill.
However, these services have to accommodate the technologically less capable. So the degenerate reduction to basically “ok, we’re going to do this the hard/easy way. You just have to click where we tell you to. It’s kinda tedious, but just push the singular buttons we tell you to.”
Re: Why don’t we do email verification in reverse?
#13How many users will abandon at the first mailto link?
My guess: 95%
Re: Why don’t we do email verification in reverse?
#14A general rule of thumb I've built up over the years: resist the temptation to innovate around login! Look at the most commonly used flows that are not obviously terrible and try to implement as close a match to them as possible. When I've tried to innovate around login in the past I've found that any clever ideas I come up with inevitably run into road blocks pretty quickly. Here's one example: why have a separate l…
When I started on my first project as a junior engineer I thought I was being clever to build an app without any passwords: every time you wanted to login you received a new email with a link to log you in. Technically, this worked great but after a while I received many complaints from frustrated users who kept looking for the “signup form”…
Re: Why don’t we do email verification in reverse?
#15Because most people have aliases to signup
Either mail+alias@gmail.com or mail-list@company.com.
For instance, I used admin@, devops@, invoice@, etc. in the places I worked. Each of them includes multiple users (leadership chain and the team)
Re: Why don’t we do email verification in reverse?
#16"fewer opportunities for the user to make mistakes" Really?
Fewer users, fewer opportunities.
Re: Why don’t we do email verification in reverse?
#17What’s doing the verification of the email on the server side? How does this service associate the email with the account? Specifically, what could be put in the email header or body by the MUA that is equivalent to a single use auth token?
Re: Why don’t we do email verification in reverse?
#18A general rule of thumb I've built up over the years: resist the temptation to innovate around login! Look at the most commonly used flows that are not obviously terrible and try to implement as close a match to them as possible. When I've tried to innovate around login in the past I've found that any clever ideas I come up with inevitably run into road blocks pretty quickly. Here's one example: why have a separate l…
When I started on my first project as a junior engineer I thought I was being clever to build an app without any passwords: every time you wanted to login you received a new email with a link to log you in. Technically, this worked great but after a while I received many complaints from frustrated users who kept looking for the “signup form”…
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.
Re: Why don’t we do email verification in reverse?
#19 1. Attacker goes to website, initiates signup up for an account
2. Website generates mail link for attacker to send
3. Attacker uses mail link to spoof email
4. Account is opened for the attacker using email address
This attack is impossible if the website sends a verification email to the user's inbox which only the person who controls the inbox has access to.
Hence, while the proposed method is interesting, it exposes the user to an unnecessary attack vector.
Re: Why don’t we do email verification in reverse?
#20This 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…
I'd argue the crux is about proving that Me The Service can send You The User whatever info is needed (password reset, notification of planned downtimes, pricing changes, warnings about service abuse) to this address - and you'll get it.
I don't care about you "controlling" an email address - you can easily get fake ones for free. It's about both parties having agreed _at least once_ on a way for the service to communicate important stuff to you.