Lack of HTTPS + questionable metrics = don't rely on it.

Share this story

A new website published by chipmaker Intel asks readers "How Strong is Your Password?" and provides a form for estimating the strength of specific passcodes. It's too bad the question isn't "How Strong is your Password-grading site," because the answer, unfortunately, is "not very."

The most glaring problem with the site is its failure to use standard HTTPS Web encryption. Based on the secure sockets layer and transport layer security protocols, HTTPS ensures that a Website being accessed is authentic and operated by a legitimate entity, as opposed to a knock-off page created by someone who is able to control the end user's Internet connection. It also encrypts traffic sent between the end user and site to prevent anyone else from eavesdropping. It wouldn't take much effort for someone to create a convincing replica of the McAfee-powered site and substitute it for the real one on a network in a coffee shop, at a conference, or in another setting. At that point anything a visitor typed could be sent to the attacker. Authoritarian regimes have also been known to inject code into legitimate sites to log account credentials.

To be sure, there are caveats. The site instructs users: "PLEASE DO NOT ENTER YOUR REAL PASSWORD," but I'd bet some percentage of users will ignore this request. Even then, the attack wouldn't reveal the user name corresponding to the password, or even the service or site they belong to. Still, the attack could be used in campaigns aimed at a specific individual or group to gain important insights about the passwords the targets use. More importantly, I'd expect a site with a goal of educating the masses about password security would tell users they should never enter a password on a plain HTTP connection. And I certainly expect Intel and its McAfee subsidiary to offer HTTPS on their own sites. The lack of encryption and authentication is surprising. I'd strongly discourage readers from entering any passwords they trust or use to secure important accounts.

The other problem with McAfee's site is the methodology used to rate the strength of passwords. The site estimates that it would take six years to crack the passcode "BandGeek2014" (minus the quotation marks) and three months to crack "windermere2313". Last week, I shoulder surfed as Jens "Atom" Steube, the lead developer of the freely available ocl-Hashcat-plus password-cracking program, decoded most of a list of 16,000 cryptographically hashed passcodes that were leaked on the Internet several months ago. It took him less than 30 minutes to break both of those passwords.

Conversely, the site says it would take only two years to crack "nIGpkQ8s.W6". That's a password I randomly generated for the purposes of this article, one that likely could be cracked only through the computationally painstaking process of brute forcing. Because it contains 11 characters and uses numbers, symbols, and upper- and lower-case letters, there are 9511 possible combinations, a massive "keyspace" that could take real-world crackers years centuries to exhaust.

The Intel site doesn't explain how it arrived at the conclusion that "nIGpkQ8s.W6" is three times faster to crack than "BandGeek2014"—and ultimately it doesn't matter. What's important is that this site should never be trusted with real passwords and can't even be counted on to give realistic assessments about the relative strength of passwords. By asking users, "Are you hackable or uncrackable?" it's crossing uncomfortably close into what security guru Bruce Schneier calls "security theater."

In the coming month or so, Ars will publish a series of articles showing how passwords are cracked in the real world and techniques end users can follow to prevent these attacks. Stay tuned.

Promoted Comments

Yes, right around the time we invent a flying submarine. Multi-factor authentication will, by definition, require carrying around some gadget, whether it provides a token or scans your body. That's inherently inconvenient.

And, ubiquity doesn't help. If a third party provides the gadget, you now have to figure out how to trust that third party.

I'm going to be 100% honest here. I am so TIRED of being told that my passwords suck, they're not good enough, and that I need to be smarter about my online security.

I know that's all true. But dammit man, I'm only human, it's becoming increasingly more frustrating just trying to use the internet now that every single website makes me log into some sort of account and then gets hacked and makes me change it.

Not to mention I should be using different log in names and emails for anything important. Which only compounds the issue further. How many email addresses am I supposed to keep up with?

Look, I get it, it's critically important that I take my security online seriously, but I am just tired of the game. It's like having a lock on every single door in your house each with a different key. Does that make your house safer? Sure, in a sense. Does it make getting around your own house hard as hell? Yes, it does. That's how I feel on the internet. Every damn door needs to be locked with its own key and I am going nuts trying keep things in order.

Does Lastpass help? Sure. To an extent, but good luck using that randomly generated 16 digit monster to log in on your phone to that companies specific app.

Rant over. I hate passwords and we need a technology that will help us move passwords beyond their glaring weakness, that we're all stupid mortals.

I appreciate your candor, and agree it's an annoyance.

I hate security questions, especially when they make you pick 3 from a short list, I manage my passwords well, but now I'm doling out personal information to all these sites so that some jackass who knows my mothers maiden name and where I went to high school can reset my account? That's more likely than them figuring out my passwords. So then you're using fake information for those questions but have to keep track of all that just in case? Screw that. I like using a phone number for recovery, but most sites don't let you get rid of the security questions.

So the calculation is:1. every common password string counts as a lowercase character2. every upper or lower case character counts as 263. every numerical digit counts as 104. every special character counts as 325. multiply the value of each character together6. a hacker can compute 17 billion guesses in an hour

Looking at this password checker it seemed totally ridiculous so I decided to figure out what it was actually doing. For anyone who wants to confirm my work the file in which the passwords are checked is Password.js.

Yes, the passwords are looked at locally in javascript, I can't guarantee that it does not send any information over the internet for every time I click the "GRADE MY PASSWORD" button it does request a new image from an automatically generated URL that is filled with gobbldeygook that could theoretically contain the password, though it doesn't contain it in plain text form.

So how does the algorithm work, well first it takes the password, and replaces any 'word' from a list of 'topwords' with an 'a'. The list of topwords appears to change every page load and is filled with what I presume are some common passwords from somewhere... not quite sure where. Next it generates a variable called 'entropy' which is equal to ( (26^Number of Lower Case Characters * 26^Number of Upper Case Characters * 10^Number of Digits * 32^Number of Special Characters) / 2 ). It divides entropy by what it calls standard 'comp' (I'm not sure if comp means computer or computational) power, or 2^34 and declares this the number of hours. It prints the number of hours out to the screen after a fashion (including a lot of rounding).

So what is wrong with this algorithm. Really it comes down to two things. 'entropy' appears to be intended to be the average number of tries it would take an attacker to find your password using a brute force attack that goes through passwords in a random order. Unfortunately it is actually that number only in the event if the attack already knows if each character is a lower case, upper case, numerical, or special character. As this is not the case in (practically) any real life situation, the algorithm is useless and creates a few interesting artifacts, a 8 character all lower case password takes 6 hours to break while a 8 character password with 2 lower case, 2 upper case, 2 digits, and 2 special characters takes only 1 hour.

The second issue is the treatment of words on the 'topwords' list. The list is about 140 words long, so even if the attacker knew the number and location of these words, like the algorithm presumes he does with the other characters, the logical improvement is 140^Number of words, not, what comes out as, 26^Number of words. I'm also very doubtful of the quality of this list, I'm not reproducing it here for a variety of reasons (swear words, length, dynamic nature) but lets just say I don't believe that eeeee1 is actually one of the top 140 words.

Coming up with an accurate measurement is undoubtedly hard because it requires on guessing the techniques that most hackers use for generating lists, but these are clearly not them.

A. A short word (4-5 letters) and capitalize two of the letters.B. Two different symbolsC. A four or five digit number.D A few letters from the website URL.E. Mix them them together.

A. For example, a short word could be anything. So let's use "pass". Capitalize two letters. The P and the first S in my example. So we have PaSs.B. Two different symbols: "(" and ")" for this example.C. A four or five digit number:A zip code you remember (90210, for example)D. A few letters from the website before the domain: Last four letters of this one (since this is the website I'm at). "nica"E. Mix and match. Let's go with D-B1-A-B2-C The result is nica(PaSs)90210

At google.com it would be ogle(PaSs)90210

This is a 15 character password that you make up which is easy for you to remember that's unique to every site you visit. You'll never, EVER have to write this down and it will withstand any attack for the next several centuries. If it IS cracked, only one website will be compromised (since most people use the same password for every site). It takes a few of them getting cracked before the algorithm becomes apparent, and your username is still needed to get inside.

It's not that hard, if you can remember what YOU made up in the first place and can read the URL of the site you're on. My clients all use this kind of method quite successfully.

Not to sound crass, but I think you may want to suggest something else. I think it's safe to say that many people aren't smart enough to mix up passwords between different sites. In that scenario, their key-word is going to be the same. And more than likely, the zip-code is going to be the same. So all that's changed is the first n letters that specify the site that you're on.

This just screams reproducible pattern.

/shrug.

To be fair, I am by no means any better, so I acknowledge I'm throwing stones at glass houses.But this doesn't scream security to me. Sorry mate.

165 Reader Comments

There's certainly something sketchy about the site. It also mentions a sweepstakes, but then has no link (that I can find) to the terms and conditions of the sweepstakes or any other information about it.

I've been using keepass for a while now, like having random passwords for everything, but it's unnerving not being able to remember them all. Assuming risk of re-using is greater than risk of losing all copies of my kdbx or forgetting how to access my kdbx.

I don't know about the accuracy of the site. On a whim, I put "gaussianprocess" and it says that it'll take 5572451 years to crack.

That said, I'm considering Journal article titles for passwords. "Constructing Skill Trees for Reinforcement Learning Agents from Demonstration Trajectories" seems to take 9.25117e83 years to crack. Even if it's off by a couple orders of magnitude, the password should still outlast the universe.

Thanks Dan—great and timely article. I can't help but think, though, that Intel's objective here isn't meant to create a truly scientific tool for testing passwords, as much as it is meant be to draw attention to password security for the average consumer—not the IT world.

I think "security theater" is right. But while this entertains, hopefully the average visitor will leave the page knowing about using different passwords for different accounts, etc.

The pwdmeter.js has a copyright date of 2007 on it, this is not exactly new stuff.

Granted Intel's might be smarter and do checking for different types of dictionary attacks, in which case maybe I could see them needing to offload onto a server, since JS might be too slow for the type of workloads, and such things are amazingly parallelizable and Intel has, if nothing else, lots of cores to throw at problems!

As far as I can tell, there's no evidence the Intel site sends passwords to a server. But that's immaterial. HTTP websites can be spoofed and made to do whatever the attacker wants, including slurping passwords.

Yup, I deleted my original content for containing mass stupidity.

And I agree server offloading is needed for any real password checks. But at some point, you end up just writing a password cracker and returning the run time!

Not that you can tell that from the front page login box. Since that's displayed inline on an insecure page, there's nothing stopping a MITM from replacing it with a login form that sends passwords someplace else.

And then you set a session cookie which can be transmitted over plaintext HTTP. Which technically does protect the user's password, but makes session hijacking pretty trivial.

i'm not as worried about the arguments^H^H^H^H^H^H^H^H^H^H comments system as i am whatever ars uses to post/edit articles to the frontpage. you could cause much more drama with that, then you ever could with this reprobate comments section.

So, by default, trying to access Ars Technica with HTTPS redirects you to the HTTP version.

The password submit on login is indeed over HTTPS, but the user has no way to know that the site is the real one at that point, because the login form is served over HTTP.

Strangely enough, after you login, you can access the site over HTTPS without being redirected to the HTTP site.

FAIL.

We can't serve the site over HTTPS to most users due to external assets that do not have HTTPS versions yet (and thus are not loaded by most browsers).

The popup login form is submitting to HTTPS, even if you are on the plain HTTP version of the site. The other option is to login here: https://arstechnica.com/civis/ucp.php?mode=login where you can clearly know that it is submitting to HTTPS.

Because you are a subscriber (and thus don't need to load insecure assets) we allow HTTPS for the main site. We have some more work to do in order to keep subscribers on the HTTPS version of the site though. Normal users are directed back to HTTP even after logging in.

This was all rolled out yesterday, and we're still improving it, so I think it is a bit unfair to declare "FAIL".

The Intel site doesn't explain how it arrived at the conclusion that "nIGpkQ8s.W6" is three times faster to crack than "BandGeek2014".

Your password starts with a lower-case letter, whereas the second starts with an upper-case letter.

They are probably assuming bruteforce attacks go alphabetically by character set, lower to upper.

I'm sure if you started the password with a special character, the amount of time would increase.

I think all sites should allow unicode passwords, so I can use greek letters and completely avoid anyone getting into the account (including myself).

A good theory which is easily testable. Both nIGpkQ8s.W6 and *IGpkQ8s.W6 have a crack time of 2 years. I'm leaning towards thinking this is a simple length+namespace "algorithm", aka useless.

Finally had a chance to go to the site and I believe you are correct in that it seems to be using simple, irrelevant logic.

For instance, I now think it's counting the number of numbers in the password and increasing the time to crack.

If the site wants to be taken seriously, it should at least do dictionary checks against a standard Webster's dictionary list, which is a pretty low bar and not really as big a dictionary as one should use but at least teaches people using the site that using common words to increase the length won't save you.

Would someone please explain to me the point in a "password tester" that tells you not to enter your password?

To help educate non-computer literate people (the average joe) on password security.

The tips offered are pretty (extremely) basic. I don't think this was meant for the IT savvy, just the dolts who use "Password123" or the same password on multiple sites. The "theater" of the password checker is just a system of delivering the education that comes after.

This was all rolled out yesterday, and we're still improving it, so I think it is a bit unfair to declare "FAIL".

OK, fair enough, and I don't have really have a problem with it, after all I use unique passwords on all sites and my Ars Technica account being compromised would not be the end of the world, and it would also be highly unlikely.

But then it's a bit hypocritical to condemn Intel for such "mistakes", especially since they don't submit your password to the server at all, and they warn you not to enter you real password.

...The password you enter is checked and graded on your computer. It is not sent over the Internet...

(emphasis mine)

Simply viewing the page's source reveals their JavaScript-based methodology. So, if you think it's borked, have a look at the code. It isn't easy to read, but I'm pretty sure it's all right there. I'm not bothering as I consider all such sites somewhat suspicious, no matter who runs them. Oh, and because I'm too lazy to do it, and have no motivation to do so.

I've been using keepass for a while now, like having random passwords for everything, but it's unnerving not being able to remember them all. Assuming risk of re-using is greater than risk of losing all copies of my kdbx or forgetting how to access my kdbx.

Use Bitlocker-to-Go to encrypt a USB flash drive with a long pass phrase. Print the recovery key and put it in a safety deposit box or safe hiding place in your house. Then store an unencrypted copy of the KeePass database on the flash drive (or export to a spreadsheet).

I'm waiting for the day we have 2FA as you describe, but I'm not optimistic. There are already good, inexpensive apps to enhance the security of online banking, and I was shocked to find that no bank in driving distance of my house offers any of them. I'll be amazed if anyone can both get all the authentication players (MS, Google, Facebook, etc) on board, and then sign up all the web sites, financial institutions, etc. Many people won't use one 2FA solution, but no one is going to use more than one.

I'm not sure why this was even posted since the original site (putting aside the possibilities of man-in-the-middle/spoofing, etc.) doesn't send passwords over the net (aka just uses client-side via javascript).Source code (and use of various debug tools...all independently) confirm this.In fact, the code is right here:http://www.intel.com/content/dam/www/pu ... assword.jsFunny part is the "toppasswords" variable.

anyways, I tend to use randomly generated passwords from https://www.grc.com/passwords.htm or use a pseudo-random generator and pass it through a hashing algorithm (md5sum, sha256sum, etc)./dev/urandom works

When I went to the site, just to be safe, I substituted a random character for each letter, number or symbol of my password. Just on the off chance anyone wants to know what my password is, I like to use the first letter of each word of a song. A the moment, I am using the Alphabet Song. (A 27 character password must be safe!)