2

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.

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.

  • Slack does that in a more secure way. – Tobi Nary Apr 16 '16 at 19:13
  • Welcome to Information Security! Please see How to Ask and The perfect question. Especially, be sure to actually ask a question that is not as vague as "any issues?" :) – Tobi Nary Apr 16 '16 at 19:14
2

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 live 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.

  • You may want to put your tl;dr at the top. I had just read everything when I found it. – mgr326639 Apr 16 '16 at 20:15
  • Thanks for the info. Regarding burden shifted to user, it seems another login option would be useful if the user is in a situation where they can't check email safely. – emeraldgreen Apr 16 '16 at 21:31
  • This is old but can you elaborate on the brute force against a 8 digits code being "easy"? Does this still apply if you have proper request throttling (10 / minute) and even captcha/bot protection? I don't think you can brute force it that easily if you can only do 10 checks per minute and the code only lasts 5 minutes, that's 50 tries only and if you happen to go through the bot protection. – Cristiano Coelho May 8 '18 at 13:08
  • @user1777914 your way of thought is to find one code, whereas we only need to find a code by enumerating the code space. Second, I didn’t say it’s easy. Third: You also imply that the codes are very short lived whereas for a good UX then should be fine to use until used or at least way longer than what you expect. Fourthly: circumventing Rate limiting is not difficult - rent a bot net. – Tobi Nary May 8 '18 at 13:15

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.