Passwords with spaces - Security Series #4.7

The other day in #coldfusion on DALnet IRC chat, several of us got to talking about passwords and about the simple password strength function that I had made some time ago. We worked on improving the regex and making is a better function. But then we go to talking about whitespace.

One of the people I was talking to asked "Why don't you allow spaces in password?". He saw that my password strength checker did not allow white space in it. This is something I asked myself a while ago, but I never really spent any time thinking about it.

Unfortunately, the only answer I could offer was "I dunno, I thought passwords weren't supposed to have spaces".

I know in the past, when setting up accounts on misc sites, I was forbidden from having passwords with spaces. But when I think about it, I need to wonder, why? I did a tiny bit of research after that and I found a few big sites that DO allow spaces in passwords, including Google. So this got me thinking that it is probably OK.

Why not spaces?

In some systems, passwords with spaces may not make sense. In legacy systems or systems where the password is not being hashed and salted but is instead being passed around in plain text, it may make sense to not allow spaces. Of course dealing with passwords in plaintext is not a good idea to start with, but sometimes there is little we can do about legacy systems.

Today I am talking about systems that use passwords that are hashed and salted for storage and comparison. If you don't know what I am talking about, check out my related posts.

• Password Security with Hashing Functions - Security Series #4.2
• More on Hashing Functions - security series #4.2.1
• Salting Passwords - security series #4.3
• Salting and Hashing Code Example - Security Series #4.4
• User Login with Salted and Hashed passwords - Security Series #4.5

Why spaces in passwords?

When asked about passwords with spaces, some might say "Why not?". I don't know why not. If anyone reading this does know, please speak up. Because right now, I see no reason not to allow spaces in passwords.

Let's look at an example that shows why. Assume that we are always using the best practice of using hashed passwords with a strong cryptographic hash and proper salting. And that we never use the password in plaintext in our application. NOTE: In my examples I will not be salting and I will be using a MD5 hash, which is cryptographically weak. I am doing this for readability. DO NOT use MD5 in your applications and ALWAYS salt your passwords.

So let's say I need to set up a password for an application. I am a user and I am signing up for a new account. Normally, I might use a password like this.

$im0nIsth3M@n!

Here I have taken the string "Simon is the man!" and I have removed the spaces and replaced some of the letters with special characters and numbers that resemble the characters. Almost all strength checkers would consider this a VERY strong password.

Here is what my password looks like when hashed.

6BFE2B72198A626573821B7AD45A970E

Now let's consider the same password, but with the spaces.

$im0n Is th3 M@n!

The password is now 3 characters longer and I have added one more character to the number possible characters in my password. When I hash this password, I get a very interesting result.

92EA44F92A316B2FA0C11A029604544A

The interesting part is that the string with spaces hashes to the same type of value as the string without spaces. Meaning that, if this is the only string that I ever use to compare password, then it doesn't matter if there are spaces in it. As long as the end user always includes those spaces when submitting the password, it will hash the same. And if the hash is always the same, then I can use it for comparison.

A little math

You saw earlier that if I remove the spaces from my password that I ended up with a password that was 14 characters long that contained uppercase and lowercase alphas, numbers, and special characters. Which gives me a character pool of 93 or so.

Uppercase Alpha: 26 Lowercase Alpha: 26 Numbers 0-9: 10 Special Characters: 31

26 + 26 + 10 + 31 = 93

So if we look at all of the possible combinations of 14 character passwords that contain some combination of these 93 characters we get a really big number.

93¹⁴ or 3,620,439,376,899,076,955,409,413,049

That is a HUGE number. And that is only for the 14 character passwords. If we look at the entire range of password combinations with a minimum of 9 characters and a practical maximum of 14, then the number is bigger still.

3,659,373,382,518,756,996,393,158,082

That number may not seem much bigger than the previous one, but it is actually 38,934,005,619,680,040,983,745,033 different.

So what happens if we now add the 94th printable ASCII character to the character pool? The space is considered a printable ASCII character and would bring our total possible password combinations up to:

4,250,449,449,022,675,609,075,223,040

That is 591,076,066,503,918,612,682,064,958 more possible character combinations. Damn!

Keep in mind that these numbers are not perfectly accurate since the rules of password strength will not allow many of the combinations allowed in this range. Passwords like 11111111 and 999999999999 and ABABABABABABAB would not be allowed. So the actual math is more complex and is not something I can dig into. But even when those are removed, we still end up with a password that could take more than 47,623,938,873 years to crack at 14 characters long.

So with such high numbers already, why do we need spaces?

Let's be honest. Users are not always the brightest bulbs on the tree, are they? When it comes to making complex passwords, they usually fail.

So the idea here is to encourage them to make longer passwords with more possible characters. By allowing them to use spaces and have pass-phrases instead or passwords, we may be able to encourage them to use longer passwords. Since processing power is only increasing, 8 character passwords are not enough anymore. We need our users to user longer passwords.

By allowing users to make pass-phrases with spaces we can encourage them to make longer pass-phrases, and for sites that require the utmost security we can even enforce much longer minimums lengths. Those longer minimum password lengths combined with the other typical password rules (including regular password changes) can render password brute-force attacks useless.

Possible gotcha

There is one "gotcha" in particular that I can think of for allowing passwords with spaces. So, if you opt to allow passwords, you need to consider this: passwords should not allow a space as the first character or the last character of the password.

The problem with allowing space as the first character or the last character is that, as we all know, having leading or trailing whitespace is usually accidental. Chances are that the user did not actually want "My D0g'$ n@m3 is sk!p " as their password. That space at the end was probably the result of cut and paste quirkiness, and was unintentional.

So how do we combat this? How do we ensure that accidental whitespace is not included in the password? Easy enough, we trim() the password. But wait, we cannot do that silently. We can't just trim the password and not tell the user, because what if they intentionally add a leading or trailing space?

So in our password strength checking function, we need to do something like this:

This way we force the user to enter the exact password that they want. We can then also safely trim the password before DB insertion.

Conclusion

Like I said earlier, I cannot think of a reason to not allow spaces in passwords. It all evaluates to a fixed-length hash anyway. So as long as we are never dealing with plaintext passwords, it should never make a difference.

That said, it is certainly possible that I am wrong. If you see something about this that I am missing, please speak up.