Password Rant – How Some Websites Do It Wrong

I spent the past few weeks methodically changing all of my passwords to correct my past habits of re-using a batch of complicated passwords that I have memorized. I had to change around 100 passwords for various websites and services that I use. Most of the websites made it easy to change your password but others failed miserably however several failed. If you are a user of any website that falls into these brackets and care about security please tweet, message or otherwise beg the website owner to correct the problems. Be warned, this is a long post

Background

Before I begin this rant, I just wanted to take a minute to define what I used as the criteria for a strong password. I use a password generator to generate high entropycomplicated passwords using the following formula;

• 32 characters in total
• 4uppercase letters
• 3 digits
• 3 non-alphanumeric characters (!@#$%^&**(){}[]?/><;:)
• Remaining slots filled with lowercase letters
• The password may not contain any words with more than 2 letters in it or it must be discarded

Some example passwords generated with this formula include

• 9hPtJt]taudbnxemxooRk>di85oeq_kV
• oxncfnte#vr2-phuIoyCcoaGr7h7v_mB
• jfi6bhpnxbZgKyowokrpXP<dxdb-57e?

Aside from the rules above, my other rule is that no password is allowed to be re-used on another website or service. This is to prevent me from needing to change multiple passwords in the event of a website compromise.

Each password generated is stored in a password vault that is secured with multiple layers of protection which will include:

• Only transmitted over https
• Encrypted and only unlocked when in active use and automatically relocks after a few minutes
• The encrypted password bank is only synced to trusted devices that have full disk encryption enabled at all times
• The server in which the password bank resides on for syncing to my devices is owned and controlled by me.
• The password bank can only be unlocked by entering a very complex password that I have committed to memory
• Its a secret – There are more steps that I have used to protect my password bank but these will remain a closely guarded secret. The above items are beyond sufficient for most users.

Now onto the fails

Arbitrary Password Length Limits

It infuriates me to see websites limit the length of a password to a paltry “8-12”. This not only encourages users to create simple passwords but also makes the passwords incredibly easy to defeat by brute force. Many think it is to allow the website owner to save disk space but this is wrong and here is why.

Users should be encouraged to use as long of a password as possible as this makes it incredibly difficult to brute force. In many cases a password longer than 12 characters is currently considered unbreakable via brute force attacks as long as common or dictionary words are not in use. With this said, thanks to the increasing power of GPU assisted tools, it is not outside the realm of possibility that a 18character password may be broken via brute force attacks within a few years.

There is really no practical reason for this limit as long as the website is following industry best practices by hashing the passwords before storing them. If a website is storing passwords in plain text, base64encoding or storing the password in an encrypted database without hashing the password first – they may run into issues however no website should do this. The reason is that hashing will always produce the same size output string regardless on the length of the passwords

Password	Hashed Value (SHA128)
Password1	70ccd9007338d6d81dd3b6271621b9cf9a97ea00
cipfvvGxxn@hXktphzun@\CgK4g6x6ci	5db21df10318421df8f08f85da183c57c5a5961e
Two households, both alike in dignity, In fair Verona, where we lay our scene, From ancient grudge break to new mutiny, Where civil blood makes civil hands unclean. From forth the fatal loins of these two foes A pair of star-cross’d lovers take their life; Whose misadventured piteous overthrows Do with their death bury their parents’ strife. The fearful passage of their death-mark’d love, And the continuance of their parents’ rage, Which, but their children’s end, nought could remove, Is now the two hours’ traffic of our stage; The which if you with patient ears attend, What here shall miss, our toil shall strive to mend.	30a9208897a55a2fdadb15f628087dec9751bbfc

In the above table, you will see that any password that is hashed via the SHA128 algorithm will always produce a 38 character string. It did not matter if I used a simple password, strong password or the entire prologue of Romeo and Juliet – all produce a 38 character string. Web developers should not store the password itself rather the output of the hash. Keep in mind that I oversimplified this statement a bit as not to go into the concept of salting but this does not change the length of data to store. I also know that websites should be using SHA256 which generates a slightly larger hash but it does not change my initial post.

The only thing that makes this worse is that some websites will actually proceed with the password change but only keep the first 18 characters of the 32 character password. This essentially forces you to do a lost password reset and eventually set it with a shorter password.

To sum it up – if the website is doing things according to industry best practices, there are no legitimate reasons for these limits. This could also be a sign that the website is storing the password in plain text or in other insecure ways.

Limiting Allowed Characters

When choosing a complex password, it is a great idea to throw in a few non-alpha numeric characters into your password to make it more difficult to crack. I am not talking about replacing the occasional “s” with a “$” but throwing a few slashes, brackets and commas in there for good measure. Some websites at least allow a small subset of special characters to be used but others forbid them completely. There is no reason for this as long as the website is sanitizing all input and hashing the values before insertion or comparison in a database or other function.

The common worry by web developers is that a malicious user may create a password that contains a character that can open the door up to several major security holes. These characters commonly include ;, “, ‘ and `. These concerns can be neutralized as long as the developer applies some industry best practices to both sanitize and store passwords. If you recall my previous statement about password hashes, you will notice that the hashing algorithm’s output does not include any special characters or other things that would pose any sort of risk to the database.

No SSL/TLS for Logins and Password Changes

There are a large number of websites that use out-of-the-box software packages such as WordPress, WHMCS, PHPBB, and other forums which do allow and encourage strong passwords however the website owners fail to put the website behind HTTPS to encrypt the sensitive data in transit between the browser and server. This could allow a malicious user sitting on the same WiFi network as you to snatch your newly created password in transit and use it as they wish. With tools like LetsEncrypt or other low cost certificate providers, there is really not much of an excuse for websites that do not enforce SSL.