Hacker News new | past | comments | ask | show | jobs | submit login
How Strong is Your Password? (intel.com)
22 points by areski on May 8, 2013 | hide | past | favorite | 57 comments

They seem to be making an assumption of 1.67 * 10^11 hashes per second. Based on decade-old ASIC processes, this is $100 worth of silicon if you're using MD5 as a key derivation function (using SHA1 or SHA256 or SHA512 would be no more than 2-3 times larger).

On the other hand, if you're using MD5 CRYPT, they're assuming $100,000 worth of ASICs. If you're using PBKDF2-SHA256 with standard "login credentials" parameters (100 ms of CPU time), it's $14,000,000 worth of ASICs. bcrypt, $100,000,000. scrypt, $4,000,000,000. And if you're using scrypt with typical file-encryption parameters (5 s of CPU time), $15,000,000,000,000 worth of ASICs.

Moral of the story: Whether your password is strong enough depends as much on how it's stored as it does on the password itself.

Well there's another way to look at it too: the strength of any password-based credential system relies upon the user refusing to give the password to unauthorized parties. The unfortunate consequence of this is that the user must authenticate the system (and verify the security of the connection between) before entering their password.

Intel has brilliantly demonstrated a social engineering/phishing attack here. "A street game" on New Yorkers, of all people! http://www.intel.com/content/www/us/en/security/passwordwin-...

But the strength estimates they give are far too high: What is the strength of a password which a user is willing to type into a non-https website or computer on the street?

Very low.

The algorithm they're using first replaces all "top passwords" in yours with a single lowercase character ('a'). Then, it counts the number of lowercase (/[a-z]/), uppercase (/[A-Z]/), numbers (/[0-9]/) and special (/[^a-zA-Z0-9]/) characters. It assigns lowercase and uppercase characters 26 possibilities, numbers 10, and special characters 32, and multiplies to get the number of possible passwords. This is divided by a "standard computing power" to get the number of hours it would take to crack.

This is about as rough as an approximation as you can get. For example, if your password contains dictionary words that aren't in their top passwords, it drastically overestimates the the difficulty of cracking it.

Type `"".hackability` in the console to see the code.

Thanks for the overview. It'd be nice if they could make a password strength checker that got the exact strength instead of an estimate, that would be cool (because actually building a hypercomputer is impressive).

There isn't really an "exact strength"; a password cracker exhaustively trying all permutations of letters and numbers will never find your password with !, a password cracker exhaustively trying all combinations of letters and numbers will take a very long to find "electroencephalograph" whereas a dictionary attack will find it very quickly if that's in the dictionary, etc. It depends on the order the cracker is trying the passwords in.

"exact strength" depends on the algorithm being used. If you're just checking dictionary words, some passwords would be really weak; if you're exhaustively checking every combination of characters, the same passwords would be pretty strong, and a different set would be very weak.

Wonder how many filtering proxies got triggered by the NSFW words in that list. Would be funny if Intel.com got temporarily black listed.

  > Step 3: Diversify your social passwords for added security 
  > "My 1st Password!: Twitr" 
  > "My 1st Password!: Fb" 
  > "My 1st Password!: Redd"
This is a terrible technique, because it's only marginally better than using the exact same password everywhere. It shares the same weakness in that as soon as your password is compromised in one place, it's as good as compromised everywhere else.

A simple way to make this a bit harder:

stty -echo; echo `read | sha1sum` LittleBitOfSalt | sha1sum | cut -c 1-40 | pbcopy; stty echo

Then paste whatever ends up in the clipboard as your password.

pbcopy is MacOS X specific I think, but IIRC there was similar way to shove stuff into clipboard on linux. Else you end up with (1) password on the screen (2) immense pain typing 40 senseless hex chars :-)

Both Intel's contest and the test at http://dl.dropboxusercontent.com/u/209/zxcvbn/test/index.htm... mentioned elsewhere in this thread seem to be relatively happy with the result..

The fully random passwords with the password manager are probably better though...

Yes and no.

If someone is attacking you personally, yes.

If someone attacks a group that includes you, breaks one of your passwords, and posts a dump on the internet, yes.

But if someone gets some password database, bruteforces all the passwords under 20 characters, and now has a username-to-password map with a million entries.... you're probably safe from that attacker using your username/password on other services. So I'd say that it's better than "marginal".

So it depends on what attack scenario you're defending against. Which is true for all safety judgements.

In Soviet Russia, the attacker gets chosen by you!

There are clearly some problems here.

"bacon giraffe coffee paper head": 2 weeks

"coffee banana tourist nose": 15368 years

Or even worse:

"i like salt": 18 years

"i like pepper": 9 hours

> "i like salt": 18 years

> "i like pepper": 9 hours

Well that's clearly because salted passwords are more secure.

Let's add a few more for fun.

"salt tastes ok": 324658 years

"intel password sweepstakes": 8441109 years

"dictionary attack": 390 years

> Lorem ipsum dolor sit amet, consectetur adipisicing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat. Duis aute irure dolor in reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla pariatur. Excepteur sint occaecat cupidatat non proident, sunt in culpa qui officia deserunt mollit anim id est laborum.

CONGRATULATIONS! It would take about Infinity years to crack your password.

I entered two password modeled after my password, and it said the first was rated at 22 seconds, and the second -- swapping out special characters for other special characters, etc. -- was rated at two weeks.

Which inexplicably gets 182,598,077,247 years. This thing clearly does not understand how to judge passphrases.

For comparison, here is the best password checker I've found:


Perhaps this is a stupid question, but your password checker claims "vertex112" would take 3 months to crack, but "vertex1123" only 3 days to crack. Why would adding an additional, non-repeating number make it easier to crack?

FWIW, repeating 'ab' 8 times as a password gives 'centuries' worth of crack time (i.e., 'abababababababab').

(I am very impressed by the password checker though; it's difficult to cover all scenarios)

Their advice for diversifying your passwords is not very good. If you are using the same password stem with a suffix determined by the site name, as

"m1p.5AsGs9LXo_HN" for HackerNews "m1p.5AsGs9LXo_RandomForum" for some random forum "m1p.5AsGs9LXo_WF" for Wells Fargo

and the random forum's database gets popped, how secure do you think your Wells Fargo password "m1p.5AsGs9LXo_WF" is? Less than 12486848 years. That goes from the realm of password cracking to some guy typing out all the abbreviations he can think of for Reddit or Twitter.

In case you're wondering, Wells Fargo will not accept "m1p.5AsGs9LXo_WF" as a password - too long!

That's the one thing which always leaves me speechless: what is the purpose of having an upper bound on password length?

To me, it always feels like they're putting up a humongous, blinking sign proclaiming "Proudly storing your passwords in plaintext since 1991!" (Most notable offender, last time I checked: Skype)

In practice, there will be some part of the system that breaks first when a password or any other field tries to grow infinitely long. Having a defined upper bound from the beginning of the design means you have a testable requirement.

That said, there's no excuse for setting the upper bound so low that any human ever gets their actual choice for a password rejected.

It doesn't necessarily mean that they're storing it plaintext (ie it could simply be a front-end input validation). But in any case it doesn't inspire confidence that they're following best practices.

I'm somewhat skeptical of "we have a validation rule here, but it doesn't validate against any actual requirement, we just threw it in for the heck of it [image of dog piloting an airplane]." Even the bizarre "well, we have a CHAR(20) for the password, so we can't save anything longer" sounds saner than that ;)

Yes, lets teach users to type their passwords into "checking" tools. Great.

edit: on the plus side, "CONGRATULATIONS! It would take about 2546476408336 years to crack your password."

(I typed in a password that was roughly equivalent to a very secure and memorable one I memorised but have never found a use for. It's a correcthorsebatterystaple style password.)

> correcthorsebatterystaple

In general, including the spaces is a better idea, because collisions.

I don't understand

If you want to maximize entropy, you want to avoid collisions.

Say we're taking strings of one or two words, picked randomly. With spaces, there's an equal chance of any string that can be generated. Without spaces, "therapist" has twice the chance of the typical string, which is some information an attacker could exploit.

Why on earth do you need to confirm your password in order to check it?

And if, as they say, "PLEASE DO NOT ENTER YOUR REAL PASSWORD", why do they need to use a silly password entry field?

EDIT: This video explains it: 10 hidden cameras. http://www.intel.com/content/www/us/en/security/passwordwin-...

This whole thing is a pretty poorly-thought-out and fairly counterproductive "Change Your Password Day" marketing move. That whole idea gives people the impression that "change your password often" is the thing to take away.

so they can log it correctly :)

I'm still against using passwords at all. In today's society it's completely unavoidable but instead of expecting people to go through the trouble of maintaining a different password for every site we should be trying to move websites in the direction of using tools like public key authentication and two-factor authentication. The future of internet security will be better if we make life easier for the end user.

And while public key authentication may seem difficult to implement server-side by doing such a thing you will never risk a database password leak again.


interesting toppasswords string. wasn't there a post a few weeks ago about how someone owns a patent on telling you your password is common?

edit: indeed there was: https://news.ycombinator.com/item?id=5543393

"Step 3: Diversify your social passwords for added security" Newsflash: appending a three-character string " Fb" to your use-everywhere password flies directly against Steps 1 and 2 ("Increasing password length is more about strength than it is [sic!] complexity", "Use multiple passwords").

Also, "Password" as a part of an example password? "Append a special character"? What is this, 1995?

Nice idea with the entropy checker, though.

password = 0 seconds

password1 = 0 seconds

password12 = 0.0002 seconds

password123 = 0.0027 seconds

password1234 = 0.0272 seconds

Conclusion - password1234 is 100 times safer than password12. Thanks Intel! Changing my passwords now!

I thought Intel's stock was doing okay. Looks like they have moved on to phishing scams...

Ok I typed in my password, but nothing happened!

Since the XKCD comic was already pasted here, instead some fun read.

"realistic password strength estimation" https://tech.dropbox.com/2012/04/zxcvbn-realistic-password-s...

I use the Stanford PwdHash extension, anyone else?

I think it's a solid scheme for using unique passwords on every site, based on just having to remember at minimum one input password.


I used to do this, but there are still so many annoying websites that require certain characters or maximum length, or other patterns, to your password. I would use a PwdHash for some websites and not for other websites, and then have to remember which sites I used PwdHash and which I didn't.

I finally settled on 1Password for the iPhone. I don't remember any of my passwords. I unlock 1Password, find and reveal the password, and type it in. This allows me to have really complex and long passwords. I always have my phone on me, as I use 2-step authentication for every service that provides it. In the rare event I forget a password, I still have email fallback recovery.

KeePass and a YubiKey.

CONGRATULATIONS! It would take about 2.956558857989926e+39 years to crack your password.


Too bad you just gave it to Intel, and over plain text.

All I can think of is: http://www.ismytwitterpasswordsecure.com/

(No, that's not a phishing page)

This doesn't seem supper reliable

abcdefg123456! < 1 second

abcdefg!123456 < 1 second

abcdefg1!23456 = 5 seconds

a!bcdefg123456 = 1 week

Moving the ! supposedly increases the difficulty several orders of magnitude.

That's because 123456 is a common password, as is abcdefg, so they're assuming that they will be in dictionaries and rainbow files, so they count them as a single letter.

Your first password, they interpret as aa! Your second, a!a Your third, a1!23456 Your fourth, a!bcdefga

Does this take in account different hashing algorithms and estimated brute force speed for each?

it does not. it simply looks at the number of uppercase, lowercase, digit, and special characters (no spaces, etc.) fairly naïve.


Something like 30 spaces is very secure, apparently.

Well yeah, seeing as most bruteforce won't include spaces and even then would have to do a-z1-3 a bunch of times before it gets there.

Looks like a great target for phishers to knock off.

Not really. You'd need a second credential, i.e. a username or email address. Not that many people would be dumb enough to enter their username and password to "check" how secure they are, would they?

I think we trust it primarily because it's client side code and on Intel's site.

good to know that : "this is a very strong password".... because it would take 1 year to crack.

And they cannot even use https ?

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact