3

I'm implementing a system where our users need to enter a special (permanent) password to authorise a transaction.

The password is separate to their login credentials, and they can only enter this auth password if they're logged in.

We want the server to generate and send the password to them by email, and we'll store a hash of the password on the server. At the user's request we will be able to refresh this password.

I've looked at other questions, such as Is sending password to user email secure?, and it seems that the issue isn't with sending passwords, but storing plaintext passwords.

Is there anything I should be concerned about with this process?

Community
  • 1
Stuart Kemp
  • 33
  • 4
  • Is the password permanent or does the user need to get a new password for every transaction? – Anders Apr 21 '16 at 11:27
  • it'll be permanent until they request a new one – Stuart Kemp Apr 21 '16 at 11:41
  • Could you please [edit] your question to include that information? It is ecnouraged to ad new information to the question so people don't have to read through the comments. Thanks! :-) – Anders Apr 21 '16 at 11:50
  • Related: http://security.stackexchange.com/questions/117730/why-would-a-website-that-resets-your-password-to-one-of-their-choice-be-consider (Quote from answer: Available attack vectors: Intercepted email on the fly, access to email account in the future.) – TTT Apr 21 '16 at 12:55
  • True, but in this case the password doesn't grant access to the account, and the user must already be logged in before they can use this password – Stuart Kemp Apr 21 '16 at 15:31

4 Answers4

4

Yes, several things. While this is unfortunately standard procdure, it's a bad idea:

  • Those passwords should be invalidated after a short period of time (and especially if the emails are not end-to-end encrypted).

    There are good chances, someone else has those passwords, too, because Emails are post cards rather than letters.

    If the passwords are invalidated that fast, most users might not be fast enough to enter them themselves.

  • If your website is not TLS all the way (or something goes south, via XSS or malware), there is also a good chance that an evesdropper can hijack the session and also access the password (if it's sent unenctypted).

    This is especially true for free, unencrypted WiFi, as many users check their emails unencryped, exposing the password right away. An automated approach would always be faster than the user.

A better approach would be to use an TOTP with a second factor (such as a smartphone app or a security token. There are apps for that for all major smart phones (Google Authenticator being a big one, but other apps can be used as well) and security tokens are next to nothing in purchase.

If that is not an option, try to fall back on another out-of-band communication channel such as SMS or automated voice calls reading the password out loud and invalidating it 10 seconds later.

Side note:

and it seems that the issue isn't with sending passwords, but storing plaintext passwords.

That's not correct, there are different issues and risks with both.

Tobi Nary
  • 14,302
  • 8
  • 43
  • 58
  • Usually, when sending mails, the mails are stored and processed, and may reside on middle man servers as reference/log files, this may leak the password to the middleman – Ferrybig May 09 '16 at 09:50
1

it seems that the issue isn't with sending passwords, but storing plaintext passwords.

No, the issue is indeed with sending passwords.

Storing them in plaintext is a different issue (the two can occur at the same time of course).

If you send passwords via email, access to the users email means access to the password (eg gained via brute force, if a user didn't log out, etc). It also means anyone in-between the users email client and your mail server may be able to access the password.

That is why the recommended approach is a one-time token. Access to the email still means access to the token, but it's something that can be recorded, and the user can be informed about it, which mitigates the risks.

Depending on your specific situation, you have to decide if the risks of exposing a secondary password are high enough to rethink your approach, or if you are willing to take this risk.

tim
  • 29,018
  • 7
  • 95
  • 119
  • Thanks. We're planning on using a one-time code with our buyers, but I've been asked to implement this system for our seller accounts. I'm not sure why we're using different approaches, but I'll make sure we've though about the risks – Stuart Kemp Apr 21 '16 at 12:03
0

Is this a one-time-use password connected only with a particular transaction? If so, then the solution is rather secure (and it is similar to the solution used by many banks - using one-time-use pincode sent over a text message (SMS) for authorizing transactions).

Jakub
  • 840
  • 7
  • 11
  • This is just not right. SMS is an out-of-band communication whereas sending emails is using the same communication means as the website. Hence, if an evesdropper is there, emails should be expected to be exposed as well. – Tobi Nary Apr 21 '16 at 11:42
0

Send a password by email is not considered to be secure.

There are several issues with sending passwords by email:

  • The email travels in plain text across the internet. As a result, a Man-in-the-middle could intercept the email containing the password. (a MitM attack is a very real thread, even more so with the wide prevalence of public wifi spots).
  • The email is likely stored (for a long time) in the user inbox. So, there is a plain text copy of the password, in retrievable form, store to see for anybody who may have access to the users inbox (for example, a coworker taking a peak at an unattended workstation)

If you only send them a 'one time' password by email though, the practice is deemed secure enough.

(Apart from this issue, you should, of course, never store password in plain text)

Jacco
  • 7,402
  • 4
  • 32
  • 53