4 Answers
4

Anything you send by email is potentially spied upon. That's how email security goes (there's none). So sending confidential data by email is an issue. We still do that occasionally, but that's because we have no better choice. But we apply mitigations:

The password is "one-time" meaning that if it is intercepted and used, either the real recipient already used it (and then the attacker is thwarted), or the real recipient will notice the problem when trying to use it (and then the attack is at least revealed).

The only allowed use of the temporary password is to reach a page or screen allowing the registration of a more permanent password, chosen by the user himself (i.e. a password which did not travel in an email).

Such passwords are generated randomly, so that they are individually strong, and it is not possible to "guess" the next temporary password, even after having observed a lot of previous passwords.

There is no need to store passwords in plain text anywhere, be they temporary or permanent. What the server must store is something which allows verifying a given password, i.e. a password hash.

Temporary-passwords-by-email are also often called "password reset links". That's the same functionality, only with an extra https:// so that the temporary password may be "typed" with a mouse click.

You are correct that this is not strictly speaking secure, but it is also the best we can do. The passwords should be one time use and require the user to change their password upon use. So if the user actually requests it, then they will know if someone else uses it before them.

If they didn't request it, unless there is a more secure means of contacting them other than e-mail, e-mail is the only option that is available to reach them. It is possible the e-mail could be intercepted and they wouldn't know that an attacker requested the change, but the next time they went to login, they would be unable to and discover the breach that way.

Could someone potentially figure out the algorithm they use to generate these passwords?

That depends. My approach would be to simply generate human-readable output from /dev/urandom, in which case this is not likely?

also these temp passwords have to be stored somewhere in plain text, correct?

Actually, no. If the site in question uses secure password storage schemes, i.e. salted slow hashes such as bcrypt or PBKDF2, what they need to do is store the derived hash of the password. In essence, it's the same as if you had instructed the server to change your password, except done on your behalf by the server.

The window for keeping that password in memory is therefore as long as it takes to generate it, send it in an email, hash it and store it.

Now, the real meat of the question is really is this a secure way to send somebody a password? The answer to that is not really, but the alternatives are:

The second option is likely prohibitive. The latter is not good password storage. The first option is "as bad" in the sense that all you need to hijack the account is access to that email.

I think, combined with a time-limited use window for this password reset, at present this is the best solution that is possible for general use websites that don't have the infrastructure to support other methods of password reset.

All of this answer assumes getting a password reset email/link requires knowing something about the account other than just the email address. Secret questions are a whole other can of worms, so let's assume that getting the password reset link/email is at least more difficult than knowing the email address.

I do not think its a security risk, since if you are using a good email provider like Gmail, it will enforce (SSL/TLS) encryption on all its communication.

As long as the only one with access to the email account is you, and no one is looking over your shoulder while you read your emails, the security of passwords sent in email is equal to submitting your password in clear text over an HTTPS connection.

However, if the password is sent in clear text, you should change it as soon as possible, a password left in clear text in an email message could be a security risk later on.

I have never seen a provider that enforces TLS for SMTP communication, certainly not Gmail. Please do provide an example if you can. Plenty of them support TLS for mail submission and retrieval (IMAP and POP) however TLS is usually only used for the encryption, not authentication. Web mail providers often use TLS for the web interface, but SMTP is still nearly always clear text, even when STARTTLS is available. @TomLeek's answer mentions that, when done properly, these "passwords" are single use so changing of passwords must happen immediately after login.
–
LadadadadaMar 15 '13 at 23:04