How to communicate user IDs and passwords

Opinion
Aug 25, 20054 mins

* Risk analysis of system for telling users their IDs and initial passwords

An acquaintance recently posed a practical question about security procedures to me and it may be useful as an example of risk analysis.

“Howard” (not the real name) wrote:

“I need some guidance on a security issue/concern.

“My corporation’s network system is now being set up to generate passwords based on a user’s date of birth. For instance, if Joseph Brown’s birth date is July 17, 1955, his initial password would be 071755. Typically the user names are generated by using the first character of the first name followed by the first seven characters of the last name. So, for example, Joseph Brown’s user name would be ‘jbrown.’

“When we send new employees their user name and password, to ensure they actually get the information, two e-mail messages are sent to their non-company e-mail address and one printed letter is sent to their home address. E-mail #1 contains the user name, e-mail #2 (sent 30 to 60 minutes after e-mail #1) contains the password, and the letter contains both.

“Our question is this. Is it more secure to send one e-mail containing the actual user name and a subsequent e-mail containing the actual password OR to send one e-mail containing the user name and, contained within that one e-mail, an explanation of the password schema without direct reference to the password itself? For instance, this e-mail might say something like ‘Dear Joseph, your user name is and your password is your six-digit birthdate in numeric values.’

“Neither of these is as secure as they should be, but which of the above provides less opportunity for someone to ‘steal’ the information? I can see the flaws and holes in both.”

I answered Howard as follows:

It’s so nice to see someone actually THINKING about security issues! Congratulations!

The use of the birthday numbers as an initial password is an awful idea – surely it would have been just as simple to use a random-number generator – but never mind. Since the password has to be changed immediately after the first use it’s really not a huge problem. At worst, a (wo)man-in-the-middle attacker who logs on fraudulently could send out a bunch of horrible e-mail in the legitimate student’s name, lock the account with another password, and have the depredations discovered instantly when the legitimate user tries to log on.

Best practice dictates that you not e-mail OR mail the user ID and the actual _password_ in the same message.

We can be sure that the password generation _algorithm_ is not a secret (everybody in the company is going to know it), so sending it separately is pointless – there is little to be gained by separating it from the user ID.

Therefore go ahead and send the user ID and the rule for creating the password in the same message. However, you might want to stipulate that the sequence is MMDDYY, since some people prefer DDMMYY and others (the logical ones) use the obviously superior and sortable (YY)YYMMDD.

Note that there is a small probability that a few people will have entered their birthday incorrectly in the Human Resources records and that therefore they will not be able to log on successfully, but that problem will be resolved by the Help Desk. The other risk is that birthdays are not generally viewed as confidential information, so there may already be attackers who know or can determine the birthday. The Human Resources department also has lots of people who will be able to find the birthday, but let’s assume that we can trust them for a one-time password.

On the whole, then, considering how wretched passwords are as a means of authentication, sending the user ID and the algorithm together is not as bad as sending the user ID and the actual password, whether together or separately.