Passwords are always a sensitive subject. Most people find them annoying, particularly when you bring in complexity. Most people struggle remembering their children’s cell phone numbers and now you want them to remember something at least eight characters long comprised of upper and lowercase alphabetic, numeric and special characters? And you want me to change it at least every 90 days? In the immortal words of John McEnroe, “You cannot be serious?”
Complex passwords are the bane of users’ lives. Most users need to remember on average at least three passwords, so anything you can do to make password complexity easier on users, the easier your life will be. While I would like to take credit for this idea, it is not mine. I attended an IP3 information security conference a number of years ago. Ken Kousky was the instructor and passed along this idea that the more I thought about it, the more sense it made.
The premise is that most security standards require that a password be comprised of a minimum of eight characters. Those eight characters need to include upper and lowercase alphabetic, numeric and special characters. In addition, a lot of standards go further and require that no alphabetic, numeric or special character be repeated in the password.
Mr. Kousky said, “What if you make the first four characters something everyone in your organization knows and you leave the last four as numeric digits that your users randomly select? Make the first set of four characters hit the upper and lowercase alphabetic and special characters requirement. You can tape this onto everyone’s keyboards or displays because it is common knowledge. All your users have to remember is their unique four digits. It is no more difficult than them remembering their PIN for their ATM.”
Think about this statement for a while before you blow it off as being too easy to be true. A lot of life’s complexity is introduced because people charge ahead without thinking things through to come up with a sane way to accomplish what was asked. After all, the simpler you make something; the more likely people will comply with what you are asking them to do.
To be fair, there are a couple of other parameters that need to be in place in order for this concept to work. First, you need to only allow a user three attempts to logon before you fail them. Since you are only relying on a four digit number for uniqueness, you cannot offer more than three logon attempts without creating an environment where someone guessing a password gets too many attempts at any one time. Next, you need to lock the account for a minimum of 60 minutes after three failed logon attempts. Such a long timeout will frustrate and defeat most people trying a brute force password attack. You need to force the user to call the help desk and properly identify themselves in order to get their user identifier re-enabled and their password reset if they wish to logon before the 60 minute wait time. And finally, any password reset requires the changing of the password at the first logon.
I just wanted to share this simple yet effective way of achieving password complexity without creating a nightmare for your users.
PCI Guru 
hi! on password encryption, particularly
DB application passwords, is it ok to use AIX EFS or Windows EFS?
i know Windows EFS is not allowed for use in encrypting cardholder data due to key management issues, is this the same for passwords?
another note, what are possible compensating controls for non-changing of DB application passwords every 90 days? would split knowledge of the password cut it?
Encrypted File System (EFS) can be used to encrypt data on Windows systems. But you are correct, key management can be a pain even with EFS.
What you are likely thinking of is requirement 3.4.1 which requires that any whole disk encryption is not integrated with the OS. As a result, using BitLocker integrated with Active Directory is not permitted. The rationale of the Council is that BitLocker implemented this way relies on the computer’s TPM chip and Windows authentication credentials which, as long as the disk remains in the original system, means that only the Windows credentials are protecting the encrypted disk.
First of all, PCI DSS v2 requires password length of at least 7 characters, not 8. Also, it does NOT require special or uppercase character classes. Please read PCI DSS requirements 8.5.3 and 8.5.9 through 8.5.14. Your solution is certainly possible but if anyone showed it to me I would not allow it by the virtue of passwords being secrets by definition; 8.5.3 also states explicitly initial passwords should be set to a unique, random value, clarifying the intent of the standard. Your suggestion is an ill advised, insecure practice bad for security and a clear attempt to circumvent the prescribed password complexity policy.
While you accurately point out the specifics of the PCI DSS, the point of this post was to explain to people a simple way to comply with the DSS without hardship on the end user.
That said, what I described is no better or worse than some of the other schemes for developing strong passwords that can be easily remembered. The PhD from Bell Labs that came up with this approach also fought with a number of people that said it was not appropriate. However, I stick with the recommendation as it works much better than telling people to come up with their own solutions which are worse.
Interesting!
I wonder what you think of the password-complexity-reduction idea I came up with a few years ago?
Interesting approach and I like it.
Bill Cheswick from AT&T Labs promotes the use of three passwords. He has one password (‘unimportant’) that he uses for sites such as the local newspaper, Wall Street Journal, Blog sites and similar. If this password is compromised, it’s no big deal. He has another password (‘important’) for sites where the compromise of the password would be inconvenient. These would be sites such as Amazon.com and other on-line merchants. Finally, he has a third password (‘critical’) that he uses only with sites such as his bank or with his work logon. If this password is compromised, it is a very bad thing. All of these passwords are created as fairly strong in that they all are compromised of upper and lowercase alphabetic, numeric and special characters. However, his ‘unimportant’ password would be only eight characters in length, his ‘important’ passwords are at least 10 characters in length and his ‘critical’ password is at least 12 characters long. You still have to periodically change these passwords, but you only have three to remember.
Now that is so simplistic and yet powerful that it’s pure genius.
Essentially, you are advocating switching to a PIN type 4 digit password instead of the complex password that is mandated by the standards and OS and software!
All the complex requirements are confined to the “publicly Key” part of the “Password Key”.
Why get around the current requirement in this fashion. Just switch to 4 digit PIN type password that meets all the password complexity requirement.
No, I am advocating making password complexity easier on users. The PCI DSS requires a 8 character long complex password. It does not dictate how you accomplish that objective. I am just suggesting a way to meet the requirement, without making it onerous on your users. What was suggested by Mr. Kousky meets the PCI DSS requirement. Yes, it does technically reduce things down to a four digit PIN. But then how many ATM thefts are accomplished by brute forcing someone’s PIN? Very, very, very few because of the other security policies that are in place with an ATM.
Also remember that the password is used as the hash to secure the authentication process until a session is created. The length and complexity factors ensure that the initial authentication request is reasonably secured and cannot be easily decrypted by anyone listening on the wire. If you were to use only a four digit PIN, the initial hash would not be very strong and could be readily decrypted quite quickly using a rainbow table. However, with the complexity rules in place, rainbow tables can still be used, but the size of that table is huge compared to one only dealing with a four digit number making decryption a much slower process.
I am sorry but you incorrect. The rainbow table size is the same for a 4 digit number as it is for a 100 character string where the first 96 characters are a standard prefix.
here is the code to generate both
For(i in range(10000 – 1)):
AddToHashTable(i.ToString(“0000”))
For(i in range(10000 – 1)):
AddToHashTable(“MY COMPANYIES PREFIX !” + i.ToString(“0000”))
Notice how the Code to create the rainbow table has the same number of loops. Its because:
THEY ARE THE SAME SIZE!
YOU HAVEN’T MADE ANYTHING MORE SECURE!
That “company” prefix you are talking about is akin to a username. It’s your “Public Key”. Simply making it part of your private key doesn’t help at all, because it’s all still public information.
The correct solution to your conundrum would be to use passwords as such:
“Love 4 Computers? Unnatural”
“Jake 8 Soda & Pizza 4 Lunch.”
“My mom enjoys eating @ 12:00pm”
Plain sentences that are easy to type, understand and remember, yet are very difficult to crack with a rainbow table.
or just a set of 4 random words followed by a number:
“Spring Summer Fall Winter(4)”
“Red Yellow Green Blue 255”
Or Even:
Scott Bikes@4:15
Heather Swims@7:01
As with many of the techniques I have detailed, you can even write down most of what you need and hide it in plain site. Simply make a list of 5 people who you know and put an “X” next to the person who you are using as the target (Heather) then hang another note that says “Schedule Swim Lessons at 5pm”
This could indicate to you that your password is: Heather Swims@5:00. Simple! Straight forward! and no one will ever know!
Agreed, but you miss the point. Their are other controls that stop a brute force attack and the use of rainbow tables. You are only allowed three attempts to logon and the account is locked permanently until a help desk identifies the user and resets the account and password. In addition, you cannot obtain the shadow file or password hash file from any server, so you have nothing to use the rainbow tables against. Game over.