Even Banks Can Screw Up Password Security

Yesterday, while I was scrolling through my Twitter feed, I came across this worrying interaction between a clearly frustrated customer and CIBC:

That's right, you read it right. CIBC doesn't allow special characters in passwords "to protect against cross-site scripting"!

Why is this wrong? Good question! It seems to suggest that CIBC are storing their customer's passwords in clear-text. Furthermore, it also indicates that CIBC is unaware of secure coding practices related to web application development such as input/output encoding. If they were, CIBC wouldn't be concerned about cross-site scripting.

It should be noted that this problem isn't unique to CIBC - in fact, many organizations across various industry sectors are deploying systems that suffer from the same poor design flaw. So how can one identify and avoid using sites that use poor password storage practices, if necessary?

Password Policies

By simply reading and understanding your provider's password policy, you'll immediately be able to spot whether they're insecurely storing your passwords. If they're:

1. Enforcing a password length limit; or
2. Disallowing the use of certain characters.

Then you can bet the barn that something's not Kosher. Let's take a closer look!

Password Length Limitations

Looking at CIBC's password policy, it states that passwords must be between 6-12 (note the discrepancy, below: the popup says at least 8) characters in length.

This is a sure sign that passwords are not stored securely. Why would a password length limit suggest that? Storing passwords requires disk space. Allowing customers to enter longer passwords would require more disk space, which means added infrastructure costs, if we were saving passwords in clear-text.

So they have a valid excuse right? Wrong! This is where cryptographic hashing algorithms come into play. Hashing not only protects the privacy of your passwords, but it also produces fixed-length binary/character sequences which helps simplify storage requirements.

For example, the MD5 hashing algorithm, now deemed cryptographically insecure, produces a 32 byte hex-ascii string or a 16 byte binary hash, regardless of what you're hashing. Don't believe me? Try it out for yourself:

What hashing algorithms should systems use? OWASP recommends using PBKDF2, bcrypt or scrypt for password storage; see their Password Storage Cheat Sheet for more information. The National Institute for Standards and Technology's (NIST) Computer Security Division even has a comprehensive set of special publications that discuss secure hashing algorithms as well as enterprise password management practices.

They said they're hashing all the passwords! That's good, but are they doing it correctly? Believe it or not even password hashing can be done wrong. Take a look at Defuse Security's great article, entitled "Secure Password Hashing - Doing it Right" which highlights common hashing errors. At a minimum you have to salt the hash. As a good friend of mine put it: "Little black pepper, pinch of salt and you're done!".

Character Filtering

Disallowing certain characters is usually a sign that the application does not properly escape or encode user-submitted data; and sometimes these same characters can make a system unusable or dangerous.

How so? Let's take cross-site scripting (XSS), for instance. Should a site be vulnerable to XSS, an attacker would be able to hijack other user's accounts, perform unauthorized transactions, or infect users of the system.

CIBC's fear is that if an attacker were able to use angled brackets (<, >), quotes (', ") or other special characters in their password, they would be able to inject malicious script into their e-banking application. If the password were rendered anywhere on the website without any kind of input or output encoding, this would be true.

Check and mate, you're rant is unnecessary! Wrong again! My rant is necessary. The security and software development community has already addressed this issue for several years now. In fact, many of today's popular web application frameworks have built-in libraries that deal with input/output encoding.

The fact that an organization is disallowing characters to mitigate such a trivial issue means that they don't understand application security and you should be concerned! You should be doubly concerned when this incorrect mitigation strategy is being employed for passwords; passwords should never be revealed to a user - staff or otherwise.

Why You Should Care

Why should I care? They have my all information already. Sure, but do you want some employee at company X knowing your password? Let's face it, lots of people use the same passwords for everything these days; whether it be for banking, email, corporate VPN, or social networking. What's to say that a disgruntled or curious employee won't snoop on your email one day, or log into your Facebook account. Would you still have the same opinion?

Better yet, many organizations have been breached in the last few years, including SONY, Ashley Madison, and Target. Would you be comfortable if a hacker knew your password and could log into your email or bank?

Conclusion

At the end of the day it's all about securing your privacy. If you come across a website like CIBC's then maybe you should think twice before signing up. If it's absolutely necessary, then use a unique password (as you should for all sites anyways). Using a secure password manager like 1Password can significantly ease the burden of managing and creating passwords. Finally, do the organization a favour, and send them over to this page .