Please don’t do this. For one thing, SMS is fundamentally broken as a secure delivery method. But more than that… it’s just so, so deeply annoying.

Once we're in the realm of 'you only have to remember this one password' you might as well use a password manager that unlocks with that password and does the rest for you (be it with autofill or webauthn and the likes).

Yubikeys are fine too, even as a single factor in some cases.

Literally this converted into:

1- Users abandoning on sign-ups "oh how am I supposed to find a password I will remember"

2- Users bashing us on the app store reviews: "make it super hard to sign-up" even though we only ask for username and password, not even an e-mail

3- Users logging in, liking the app, then a few months later when they got logged out for whatever reason, completely forgetting what their password was and not having a fallback e-mail.

We ended up pulling it back. We just have a small note now that says "easily guessable password" but allow them to proceed with registration.

- Our app was _deleted_ without any notice and any means of appealing (didn’t appear in the appeals page, and of course there’s no human support). We even filed a ticket and were told that they couldn’t help us because the app was “gone” in their system. Luckily we require an email address or we would have completely lost the ability to authenticate a subset of our users. - A different internal app was banned from using “Facebook Login” because we were “providing a broken user experience” — the app was not even exposed for login in our system. We couldn’t appeal because the warning notice didn’t allow responding from our mailing list. Changing the primary contact didn’t work either, and we even disabled the login on the app just in case. Still revoked with no means of getting it back.

Google has been less awful to work with, but they make you jump through lots of hoops to get public login permissions. In summary, think very carefully about a third party Oauth solution.

2. If someone has access to your email, you're screwed anyway because they can lock you out and reset every password.

Your email password, effectively, becomes the password for that website. I.e. security-wise, I think they're equivalent.

Every single one of them. Email is a plain text protocol.

There are three components worth looking at. Each of them is popularly secured with TLS.

Firstly, submission, sending an email you just wrote from your client to a server. This is usually done over a specifically TLS-secured "SMTP submission port" 587 although it can also be done with STARTTLS.

Second, relay, getting email from your server to somebody else's server. A large proportion of today's servers default to STARTTLS over SMTP for MX. So this means when they connect to a peer server to exchange mail they'll enquire about using TLS and do so if possible. A passive adversary can't stop this happening.

Finally, delivery. Almost all modern IMAP clients default to using TLS with IMAP, so this step will be encrypted. Even in clients that don't require TLS a passive adversary can't stop them upgrading by default if possible.

This is misleading. Remember our context here is that we're getting a sign-in token for some web site, let's say it's the EXA Metal Pole Limited (Europe) site, example.com

The plain text is stored briefly on EXA's outbound mail server mail-blast.example.com, and then it's transmitted to my inbound MX mx1.tlrmx.org, stored very briefly there, and passed to the IMAP server imap.tlrmx.org.

So that's three servers, but, one of them is controlled by the same people as the site we're logging into. If they want a backdoor they can just make one, they don't need to steal their own sign-in tokens, that would be really stupid.

OK, so two servers left. But those are both operated by me, the recipient of the tokens. Why am I stealing my own tokens? To what end? "Oh no I broke into my own account and have impersonated myself" ?

Now, many people use say GMail instead of their own mail servers. But can we reasonably say these people's mail was "intercepted" by GMail, the outfit they've explicitly chosen to receive and store email on their behalf?

And even if we insist upon using the word "intercepted" this way ("The Buccaneers pass was intercepted by Mike Evans" [Evans is a Buccaneers Wide Receiver, the pass was presumably meant for Mike and so we would not ordinarily call this an interception, but if you insist...]) it's unclear what unexpected gain is achieved. GMail could just build their own backdoor and sign in as you to get the tokens instead of "intercepting" them if for some crazy reason that was what they wanted.

Still we’re in a perverse situation here. Running your own server is getting harder to do since everything operates on white lists, and I wouldn’t trust the big name providers for something like this.

https://transparencyreport.google.com/safer-email/overview?h...

Password reset emails are already extremely common and a way of implementing the "second factor only" method in the OP.

This is both good and bad. When I needed a whole team to have access to my account, I just built a mailing list, and used that address for signing up. Yes, it was annoying that we'd all get email every time someone logged in on a new device, but it was also pretty straight forward to use.

edit: but infosec isn't completely equal to cryptography, so some deterrence like that will prevent some attacks. But it's like adding a real beefy padlock on your door (the hashing), and then putting a piece of tape to keep your door shut. Or putting a piece of tape over the keyhole of your padlock.

And no, pepper is not encryption. Encryption is reversible, you can decrypt the ciphertext with the key.

Hashing isn't encryption / Confidentiality isn't integrity / RAID isn't backup / Income isn't profit

Not knowing the difference doesn't mean there isn't a difference.

> An alternative approach is to hash the passwords as usual and then encrypt the hashes with a symmetrical encryption key before storing them in the database, with the key acting as the pepper.

https://cheatsheetseries.owasp.org/cheatsheets/Password_Stor...