91–100 of 329 posts
Seems like this practice died out when messaging apps (LINE) displaced mobile email. I thought it was kind of cool but managing spam filters was a pain.
I like the idea but instead of mailto which I find annoying why not simply ask the user to send us an email with a hello message? The email address we provide can be unique per sign up if required. So no copy pasting of codes, or having a specific format of the email. We just need to check the sender and recipient.
I haven't really thought this through (what an attacker would gain), just want to point out the general risk.
It's not "just" to verify that this user controls the email address.
A 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…
I usually see it when people implement add/edit for some entity, that should be separate forms but are crammed into one to be "DRY".
Earlier quoted context omitted.
Use a password manager. Problem solved.
I do and tell people to do the same. Unfortunately we can't force people to actually do it.
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.
Earlier quoted context omitted.
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”…
Oh the few websites that do this drive me absolutely crazy. It makes me immediately look for alternatives, it's unbearable
But I deliberately keep email off my phone, so I don't look at email on my phone.
So yes, I hate 'passwordless login'. I have a password manager, I can do it myself thanks very much.
Earlier quoted context omitted.
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”…
Email is not a secure method of communication.
I... 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…
You're right that SPF and DKIM are not universal (besides not being strictly for user authentication); this scheme would require a domain to have both in order to be secure and would require some kind of policy attestation around email local parts, which would exclude some email providers and some users. That's why it's "a random idea I had on the subway," and not something I'm doing in production :-)
Earlier quoted context omitted.
I do and tell people to do the same. Unfortunately we can't force people to actually do it.
Unpopular take: users should be free to use bad and insecure passwords for services they don't care about.
* not everybody has an email client set up that works with mailto: links
* sending from an address and receiving emails for an address are very different, and they don't map 1:1
* If you rely on users sending mail to you, the user doesn't know if / when their email is received and processed. They send the mail, try to login, it doesn't work. They have to wait until it's processed, and then forget about your service. OTOH if they receive a mail from you, the mail in their inbox reminds them that they signed up, and as soon they receive it they can use their account.
* I doubt that DMARC/DKIM/SPF are actually deployed as widely as OP thinks, and excluding users based on some (to them) obscure/unknown feature of their email provider is bound to generate frustration. If they self-host their email, your support might end up debugging / having to help them with their email setup.
* There are some subtleties you have to get right, like verify the MAIL FROM, not the From: header, etc. Email is actually a mine field when it comes to security (it's not specified what should happen if a header is sent twice, so some attackers try to fool virus scanners by finding combinations that the scanner interprets one way, but the recipient interprets another way, etc.) Worse, if a verification fails, it's your responsibility to debug it, and you might have to explain the subtleties to a non-technical user.