Last week, CNBC ran a piece on how to choose secure passwords. To supplement their article, they included a tool to test how strong your password is. Just type the password in the box, click submit, and CNBC will give you an estimate of how long it would take to crack the password. Unfortunately, the news outlet made a series of blunders with their tool, putting users at risk.
Instead of calculating password strength on the client (your computer/phone/device), CNBC elected to perform the calculations on the server side. Additionally, they did not use HTTPS; the passwords were sent in an unencrypted, easy to intercept format.
GET requests are typically used to ask a server for a specific web page, and shouldn’t be used to send data. They consist of arguments added to the end of a URL in the address bar. CNBC sent user passwords with GET request, meaning the passwords were visable to anyone looking over your shoulder or with access to your browser history (ie. employers or internet service providers). The GET requests were also sent to all 30 third parties (mostly advertisers) when loading the page.
To top it off, CNBC claimed that “No passwords are being stored.” Security researchers found that passwords were being inserted into a Google Docs spreadsheet.
CNBC has since pulled the article and has not responded to requests for comment from other news outlets.
Password strength checkers are a good concept, although you should never use them. They can be malicious and steal your passwords and other information. Even if they have good intentions like CNBC, they can still screw up their implementation.
CNBC’s strength checker tested passwords’ vulnerability to brute force attacks. A brute force attack is like testing every combination on a padlock: it’s slow, but eventually you’ll get it right. While a strength checker can be a useful tool for visualization, I’ll explain on paper, where I can’t steal your information.
Picture a lock on a briefcase. Imagine three dials, each ranging from 0 to 9. There are 1000 possible combinations, from 000 to 999. Assuming it takes five seconds for me to test a combination, I’ll need 5000 seconds (or about an hour and twenty minutes) to try all of them. Now imagine the lock has four dials. We’ve gone from 103 possibilities to 104, and now I need almost 14 hours to enter them all.
Imagine the dial goes from 0 to 9, and then ‘a’-‘z’. We’re now at 36 characters, and four dials. I’ll need over 2,332 hours to try them all, or 97 days. If we add capital letters, we have 62 characters, bringing us to 4104 hours (171 days). Adding two more dials gives us 626 options, which will take me almost two and a half years of nonstop attempts to open the case.
When it takes this long to crack a password, I must know there is something valuable in the briefcase for it to be worth my effort. It almost seems like overkill. If we consider that the graphics card in the budget desktop I built 7 years ago as a high school freshman could try every combination in under five minutes, it seems like a joke.
Every small increase in length or complexity will greatly improve a password’s strength. Historically, eight has been a common minimum length for passwords. Given the rapid rate of processing power growth we’ve seen over the past decades, I wouldn’t recommend using a password with less than ten characters, with numbers and a mix of upper and lowercase letters.
Next week I’ll explain dictionary and heuristic attacks, and go into where I’d find a big lists of passwords. In the meantime, if you want feedback on your password, feel free to email me at dstewar2@stevens.edu. I promise not to store it.
