
Why Intel’s “How Strong is Your Password?” site can’t be trusted - coloneltcb
http://arstechnica.com/security/2013/05/why-intels-how-strong-is-your-password-site-cant-be-trusted/
======
mistercow
The worst part of this is that a lot of their advice for stronger passwords is
idiotic and dangerous. They've taken methods that _do_ increase entropy, but
castrated them by making them systematic and predictable.

1\. Using a multi-word passphrase is smart, but only if you generate it
randomly. A novice reading their suggestion might think they can come up with
a phrase that's meaningful to them. This is very bad advice and will lead to
weak pass phrases, guaranteed.

2\. The choice to delimit the words in your pass phrase with
spaces/hyphens/title-case adds less than 2 bits of entropy to your password.
If you do it the same way that everyone else does it (because Intel told you
to), it adds zero bits. Randomly mixing in capitalization increases entropy.
Predictably mixing in capitalization does not.

3\. Adding numbers to your password is a red herring. The most likely effect
that advice will have on a user is to encourage them to choose a pass phrase
where a number fits in naturally, which will drastically reduce entropy since
it constrains the types of phrases they might choose from.

And again, randomly throwing in numbers increases entropy. Predictably
throwing them in does not.

4\. Adding an exclamation, period, or question mark to then end of your pass
phrase adds, again, less than 2 bits of entropy. Once again, random
punctuation increases entropy, predictable punctuation does not.

And the icing on the cake is that their example "My 1st Password!" reinforces
every possible bad interpretation a novice could make of their advice. Intel
should really be ashamed of this piece of work.

~~~
jamieb
What, so OnionMan77 not so good then?

[http://www.theonion.com/articles/onion-twitter-password-
chan...](http://www.theonion.com/articles/onion-twitter-password-changed-to-
onionman77,32323/)

------
mikeash
I can't find it now, but my favorite such site was one that just took your
password and replied with, "This password is completely insecure, because you
just gave it away to a random web site on the internet."

~~~
patmcguire
Also, this has been making the rounds:
<http://www.ismytwitterpasswordsecure.com/>

~~~
lucb1e
That was the first thing that came to mind as soon as I saw Intel's thing on
security.nl. Then someone commented it even sent a request to the server with
every check and I nearly fell out of my chair

------
jcaden
My password is eyh7E6y1unZdyA3489dE

What are you going to do with it? That's right: nothing.

This webpage does not send the password home (confirmed with Wireshark). Even
if you are under a MitM attack, this site would be the LEAST of your worries.
This article is mere sensationalism and should probably be renamed "Why HTTP
can't be trusted." What's that you say? HTTP open to MitM? Never!

~~~
qu4z-2
I liked the fact that it complained about HTTP more than the fact that it's
encouraging people to type their password into a random online site just
'cause it's by a "legitimate entity", whatever that means.

(Recommendations not to use your real password notwithstanding)

------
wmkn
While I agree with the sentiment in the Ars article, it seems to suggest that
your password is submitted to a remote server. The check is completely client-
side though.

[http://www.intel.com/content/dam/www/public/us/en/apps/passw...](http://www.intel.com/content/dam/www/public/us/en/apps/password-
security-toolkit/js/password.js)

~~~
thedufer
That's not their point. An unsecured site can easily be spoofed; a secured one
would require either getting intel's ssl cert or convincing users to click
through a big "dont trust this site" page in their browser.

The fact that they don't send the password just means that a MITM needs to put
in slightly more work.

~~~
tbrownaw
_a secured one would require either getting intel's ssl cert or convincing
users to click through a big "dont trust this site" page_

Or breaking into their DNS registrar and getting your own cert for their
domain, or breaking into any one of the many many dozens of CAs that most
browsers trust...

~~~
thedufer
Fair enough. Those are still generally on the order of very difficult, and
certainly more difficult than doing none of those things at all.

------
nnnnni
It really liked "correct horse battery staple", but it did not like "hunter2"
at all.

~~~
qu4z-2
Yeah, I'm pretty sure those are both in every password dictionary ever...

This site would be much better if it took the time to "crack" the password you
submitted.

~~~
CaveTech
Thousands of dollars of computing resources thrown at users of a free service
would definitely make it better.

~~~
qu4z-2
But you're giving them a plain-text password. It doesn't need to actually
crack it.

This[0] was mentioned elsewhere in the thread. It's a good approximation of
what I meant.

I realise putting "crack" in air-quotes probably didn't quite convey my full
meaning.

[0]:
[http://dl.dropboxusercontent.com/u/209/zxcvbn/test/index.htm...](http://dl.dropboxusercontent.com/u/209/zxcvbn/test/index.html)

------
gwillen
It's not possible to look at a password and determine how long it would take
to crack it, without knowing how it was generated. All you can say is how long
it would take _you_ to crack it. But just because a password looks hard to
YOU, doesn't mean it's not a dictionary word in Bulgarian or something.
There's no way for you to know.

~~~
personalcompute
It's also not possible to look at a password and determine long it would take
to crack, even knowing how it was generated (to the reasonable extent I
believe you implied, ie Bulgarian or English). Your password may happen to be
the first word in a dictionary list or it could be the last word.

It is an inherently inaccurate probabilistic estimation of an attacker's
methods, and does make any claim of being more than that.

~~~
gwillen
If you know a password generation algorithm, you can compute a lower bound on
the average time to crack a password given that it was generated by that
algorithm. Some individual password might happen to get unlucky, but you can
still have a good general idea of the strength of a password if you know the
set it was drawn from and the distribution.

------
_kst_
Apparently the password "significance" would take 317 years to crack, but
"interpolated" would only take about 6 hours.

Both are randomly selected 12-letter dictionary words (from
/usr/share/dict/words on Ubuntu, excluding words with uppercase letters or
punctuation).

------
iuguy
It's always funny to see things from HN comments come back to HN in the form
of articles a short while later. Is it just that the HN crowd are on the ball
or are the journos reading HN comments?

~~~
npsimons
I'd say at least most HN'ers are on the ball. I glanced over that original
headline and thought, "gee, let's go test our password by giving it to someone
we don't know, that sounds like a good idea" (sarcasm detector explodes).

~~~
vacri
They do say "PLEASE DO NOT ENTER YOUR REAL PASSWORD", though admittedly it's
in faint text.

------
trebor
I knew it couldn't be trusted, so I gave a spurious one (xkcd style), and it
said that it'd take a majorly long time to guess. (But entropy per character
was low, it was all lowercase!)

------
pixelcort
Regarding password strength checkers, see also
<https://github.com/lowe/zxcvbn>

~~~
sethammons
The following has a working example of that repo. I really like the
implementation, and it gives wildly different results than the Intel site.
[http://dl.dropboxusercontent.com/u/209/zxcvbn/test/index.htm...](http://dl.dropboxusercontent.com/u/209/zxcvbn/test/index.html)

~~~
mistercow
And as always, if you're going to enter your password into a page running
zxcvbn, make sure to either disable your internet until you've closed the
page, or disable plugins and monitor network requests to make sure what you
type in isn't being sent anywhere.

Or you know, better yet, just don't type your real password into it.

------
katbyte
And it claims "asdasdasdasdasdasdasdasdasd1234" would only take 12 seconds to
crack.....

~~~
qu4z-2
Do you disagree?

~~~
katbyte
Yes, i don't think its possible to crack a password that long within that time
frame, am i wrong?

~~~
tomku
Yeah, you're wrong. You'd be right if password cracking was limited to
checking 'a' through 'z', then 'aa' through 'zz', then 'aaa' through 'zzz',
but that's not how it usually works in practice.

In practice, a cracking program is generally going to have a dictionary and an
algorithm for generating passwords based on modifying and/or combining the
words in that dictionary according to certain rules. The dictionary isn't just
English words, but also common non-English words, words formed by keys that
are close on the keyboard, etc.

If that dictionary contains "asd" and "1234" (which is a pretty safe bet), it
will probably end up trying "asdasdasdasdasdasdasdasdasd1234" much sooner than
you would predict based on an exhaustive search. I can't say for sure that 13
seconds is the right answer, but I think it's the right order of magnitude.
We're talking seconds/minutes, not years.

Edit: changed "sequential search" to "exhaustive search" to reflect the fact
that it doesn't have to be strictly ordered.

~~~
qu4z-2
Thanks for taking the time to explain my comment.

I would've gotten to it eventually, but you've done a better job than I
would've anyway, so it all works out. :)

EDIT: And just so we're on the same page... This is for recovering the plain-
text password from a known hash. If you have to test each candidate against a
web-service or something it'll take a significantly longer time.

~~~
katbyte
Yes, I was thinking more along the lines of hacking into something rather then
decrypting a password hash.

------
JoeKM
I've always liked Steve Gibson's site for entropy:
<https://www.grc.com/haystack.htm>

------
chenyeric
I used a long dictionary word and it took them 5 months to crack ...

------
krapp
éxÇÏen0ôwâBümèzSäWgÎ. _Ä_ îoqëÕêiCßÒ

Come at me bros.

