[notepad0x90]

I have a couple of problems with this, although kudos for the author and I won't dismiss this project's usefulness or value.

1) Email shouldn't be used for this purpose. It is inherently insecure. Many have tried, you won't succeed.

2) The subject line of the email should not contain verification details (code), it shouldn't even imply the content of the email. "A secure message from <insert site>" is enough.

3) The device receiving the verification message is often not the same device that initiated the process. It is very important that users are able to easily type out the code in the webapp, instead of what many do: require a link to be opened.

4) Alright, use email, but don't treat as a special or absolute means of contacting users. The whole "contact user" aspect should be abstracted to a point. Any messaging app that the user would like to use should be used. There are dozens of them, and all of them should be abstracted to the webapp. Managing api keys and integrations sounds like a nightmare, this is one big reason no one is doing it. But again, that's my gripe, this is a solvable problem, services and libraries to make it easier should exist, but where they don't .. the developers of the application should take on the costs associated with supporting them. Maybe not dozens but a handful of messaging protocols, based on target audience can be used (e.g.: Signal,Whatsapp, Weechat, VK, Telegram, Bluesky, Twitter) - 7 api keys to rotate once every few months and you've just made billions of potential users happy!

5) Perhaps the problem is a lack of a "secure address resolution layer" to messaging? Without requiring api keys and all of that, it should be possible to resolve the address of a recipient, encrypt a message to them, using their public key, and simply send it. Messaging apps should support a standard protocol of receiving external messages this way. The protocol should also allow including a "reply" address?

[TZubiri]

1) Email shouldn't be used for this purpose. It is inherently insecure. Many have tried, you won't succeed.

Sorry if I didn't read the rest. But email isn't secure? Email isn't used for auth? First I've heard of such a thing

[notepad0x90]

> Email isn't used for auth?

I didn't say that, you added that part. It is used for auth. it isn't secure.

Email is less secure than SMS, unless you encrypt your email (even then..). With email, there are multiple middle parties that can just read the message. Forget malicious insiders, it is more than reasonable to assume at least one MTA out there is compromised. Mail server CVE's aren't that rare.

Furthermore, despite email being used for auth, as you correctly claimed, email clients aren't secured like authentication applications or password managers are. For most people, a compromise of their email account means a compromise of most of their other accounts.

Even furthermore, not only is email used for authentication, email is being used to revoke,reset and tamper with other authentication methods and account security in general. You don't just login to apps via email, your password, MFA, account changes,etc.. can all be done by someone controlling your email (and more and more, your phone number/SIM these days).

End to end encryption is all the rage on sites like HN, but I'm shocked when those same people have no problem using email for sensitive operations.

[TZubiri]

Sms travels through air, so it's less secure.

Also email is usually encrypted, MTA are application layer, not routing layer, and they can onlu see headers.

2fa is nice, but the first factor is usually email.

But whatever, maybe the world is wrong