Email code authentication

Question

I'd like to replace passwords with a temporary code that's emailed to the user. The login flow would go like this:

1. User enters their email address. "If that email belongs to a user, a code will be sent" message to prevent disclosure of valid emails.
2. User is emailed an alpha numeric code (lets say 8 digits long and valid for 1 hour).
3. User enters that code as their "password".

The good:

1. No passwords are stored in the database.
2. No need for password resets.
3. Much of the security burden is shifted to the email provider.

The bad:

1. An email address is required. If you lose access to it you lose access to your account.
2. If you forget your email address you lose access to your account.
3. It's inconvenient to check your email each time you log in. This would not be an issue on mobile, where an API token can be stored after the first login.

Are there any other issues, especially security related? As far as I can tell, this should be as secure as a password reset. In both situations you're emailed something that allows full access to the account.

Here are similar questions but with more focus on cookies, or without solid answers. I'm more interested in the positives and negatives, especially any security issues.

• How to implement non-password authentication in a web site
• Password-less authentication in web apps - How safe it is?

Clarity/Goals edit: The goals are to limit the amount of sensitive data stored in the database (even if that data is hashed), be accessible to average users (remotely with an internet connection), and not depend on a different device for authentication. Additionally, be as simple (UX) and secure as possible given those constraints.

Answer 1

tl;dr: It all comes down to how good the users are at keeping their mails safe. But that are post cards rather than letters. Do not exclusively offer that option. Also, seems like an xy problem.

Here are some things to be considered about this:

• You said

  User is emailed an alpha numeric code (lets say 8 digits long and valid for 1 hour).

  Let's rather say 20 bytes, valid for 10 minutes. Brute force of an 8 digit password is absolutely feasible.

  This can be passed to the application/web app via a get request from a link in the email to make the life of the user easier.

  That's what Slack is doing with it's "magic link" feature, by the way.

• You listed as a negative

  An email address is required. If you lose access to it you lose access to your account.

  and

  If you forget your email address you lose access to your account.

  This is usually the case, at least with password resets.

• You may still use session cookies in the web app to keep the user logged in longer - same as storing that token in a mobile application.

  Hence this problem

  It's inconvenient to check your email each time you log in.

is gone.

• You list as a positive

  Much of the security burden is shifted to the email provider.

  while in fact a lot of the security burden is shifted to the user, too.

  How sure are you that your users only check their mails through secure connections, without chances of eavesdropping? (Think: Open WiFi, regular POP on mobile. Happens every day.)

  This makes the user's mail box a single point of failure.

  Additionally, while have I been pwned is known by most IT-affine people, there are a lot of people out there that do not know their email is already breached because of password reuse.

  Yet, the last point is also true for password reset emails - only do they occurr less often and usually trigger additional security measures.

For whatever reason you are trying to use mails and short lived passwords, there are better ways - for example UBS security tokens that do add a "somethis only you have" part to the equation, not removing a "something only you know" part.

I'd also advise you to think about if this might be an instance of a xy problem and ask a new question with the actual problem you are trying to solve.

---

Update for the modified question:

If the passwords are hashed correctly, there is nothing wrong with storing them in your database.

Yet, if we accept as a UX decission to have the user not have passwords, using email and requesting the users GPG key and/or S/MIME certificate and sending out short-lived password links to the user using mail on request would be fine.