Password sent via email upon registration

Question

I was wondering what the pros and cons are about sending an email with the password to a user registering on a website (like wordpress.org does).

They use pretty good passwords (12 characters long with uppercase and lowercase letters, numbers and symbols). Now, assuming that the passwords are secure enough, why would someone decide to use this approach versus the traditional one (letting the users decide their own passwords)?

The first thing that comes to my mind is that, by doing this, you avoid the use of weak passwords upon registration, thus increasing security, but then allowing the user to change the password would make all this useless.

The second thing I can think of is that you could avoid the risk of credentials sent in the clear during the registration process, if the website doesn't support HTTPS. But then again, if a website cares so much about the user's security, I assume that it probably has HTTPS support too.

Is there something I am forgetting?

And to make the question more suited to this website: do you think that creating strong random password and then emailing them to the users is a good idea?

Answer 1

First, its generally a bad idea to send permanent passwords for secure things via email, especially user generated passwords (which the user may share on other resources). Your email is often automatically saved to disk if you use an email client, which is easily read by anyone with physical access to your computer if you don't encrypt your hard disk or ever leave the encrypted hard disk unlocked. Also there are generally no guarantees in email that an eavesdropper isn't reading your email messages, e.g., if you check your mail via POP/IMAP without SSL or someone is scanning your email server-side, or while the email is routed between mail servers. Granted a computer-generated password is being stored with your email may not be that much of a compromise, especially if the system allows someone with access to your email could reset the password. (And if the site uses cookies to store login information you could read cookies off the hard disk just as easily as reading email off the hard disk).

Its nice that the process described above verifies that the email address is (initially) readable by the registering user. This can also be done by requiring a registering user to click a link with a random token. Granted temporary email services like 10minutemail.com can get around this, a user may be less likely to lie as they'll want to have the password in their records.

Another nice thing is that it sets a strong password by default. Many people will not change defaults or if they do change the password, will use a similarly strong password. Consider organ donation with countries opt-in/opt-out countries. 99% of Austrians are organ donors as the default is to be a donor (opt-out), and 12% of Germans are organ donors as the default is to not be a donor (opt-in). This aspect of psychology is probably more of a factor in choosing the default for other security features like "this is a public computer (do not remember my login)", but for users who already save passwords in their browser this isn't particularly different.

The password change functionality ideally can attempt to check that the new password is sufficiently strong. E.g., is not similar to passwords in a common password list, is not dictionary word, or a dictionary word followed by a 1 or 2 digit number or punctuation mark. This could be a very annoying and more CPU intensive to make every registering user generate a strong password, but possibly less intensive if the check is only done on password change page (assuming some frustrated users give up). Also, its better to have them frustrated at changing the password once they already have a working account versus before they have one.

Answer 2

Passwords are an interesting security problem. They are the most widely-used, but appear to be widely varying in their security implementation or sometimes poorly understood.

Generally, a password is only as good as the user who wields it. Your post would appear to focus on this theme. However, passwords are also only as good as the system that manages them. The best password in the world cannot be protected if it is stored or sent in the clear. As in your question, by emailing the password, it has effectively rendered the scheme useless. It doesn't matter if the password is 12 random characters.

Passwords must also straddle the line between security and usability. Short passwords made from a limited set of characters are easier to remember. Users tend to use one or two passwords for all of their web-based activities. Longer passwords, or those with more complex character class requirements are more difficult to remember. People tend to forget these passwords more often, and if forced to use draconian complexity rules, will often write them down. Now, like Bruce Schneier, I also believe that you can write down your passwords -- as long as the location you write it to is secure. But there is definitely no consensus on this point.

Removing the opportunity for a user to change the password means that a user is not in an easy position to be able to revoke or protect their credentials (eg. if an email account is breached, or to ensure the target site and their staff do not have access). This can also be a frustrating security experience for those security-minded people who understand that password maintenance is a dynamic process.

There are numerous password-related questions on this site. Please do go through them. Some ones of interest related to the various points in your email:

• If a website allows another person to get a list of the site's users passwords, how likely is it that the passwords are stored in cleartext?: passwords stored in the clear on the server
• Am I wrong to believe that passwords should never be recoverable (one way hash)?: Passwords emailed in the clear
• Forgotten password or reset link, which is more secure to email?: Password reset links vs. emailing the password
• XKCD #936: Short complex password, or long dictionary passphrase?: Discussion on password complexity

Answer 3

PROS

• ensure that the passwords of non-techies are at least compliant to best practices (since they probably won't change it and just save it in their browser)

CONS

• the password is sent in clear-text over unencrypted email, with obvious security concerns

I would rule out any HTTPS issue, since I would be much more concerned about lack of SSL/TLS during authentication than during registration. Furthermore, a web site not employing HTTPS for its registration process, hardly will provide it for authentication.

I don't really think there are other reasons than the pro listed above. To determine if this is a good idea or not, we should probably compare the risks of getting credentials stolen in clear-text email against the risks of getting easy passwords guessed / brute-forced. As I don't have any data regarding these issues, I'll refrain from judging this decision.

Answer 4

You have two questions here and I'm not sure if you are asking if it is a better idea to generate passwords for users vs letting them choose their own or if it is better to email the passwords to users rather than showing them on the web page.

As for emailing them vs showing them you mention that some sites may not use ssl. However, email is often transmitted and stored unencrypted so this isn't much better. Plus email clients such as gmail will just keep your emails forever so many gmail accounts are a treasure trove of emailed passwords. I say if you wouldn't mail it on a postcard, you shouldn't send it via email.

As for generating passwords vs users selecting their own, one good technique is to tell users the only rule is that their password be at least 12 characters long, otherwise it can contain anything they want. That one requirement eliminates almost all dictionary words and requires users to add random stuff to a word to make it meet the minimum requirements. Plus users don't have to read through a list of confusing password strength rules, it just needs to be 12 characters long.

Answer 5

E-Mailing the user a random password does confirm that they own the e-mail address and greatly simplifies the coding required for this e-mail validation. No worries about what actions the user can or can't perform until validation because they simply can't login. No need for options to re-send the validation e-mail or having to track the validation state of each account, etc .
Although I understand why e-mail validation exists, it is still a bit of a pain. Having an initial password e-mailed does make it seem less of an extra step. On the flip side, I'm always cautious of using a site that considers e-mailing a password as good practice.

If I ever made a registration system that e-mailed an initial password, then I would insist the user change it on first logon. The password has been e-mailed, it may as well have been written on a postcard, addressed to your username, and pinned up in the local library!

Answer 6

I would suggest that the password is set by the user after following a confirmation link. The confirmation is emailed to the user. However, this isn't much different than the already suggested asking the user to change the password following first login.

Enforcing strong passwords has always been a problem, I always suggest that users record their login credentials in a password safe on their machine, which is encrypted on the local drive but has either biometric access or single password access. But I am one man and I can only cover a very tiny part of the population :).

I guess it depends on the nature/ confidentially of the data behind the password and how much control needs to be in place to satisfy the users.

TJ.