Why Intel’s “How Strong is Your Password?” site can’t be trusted
arstechnica.com
arstechnica.com
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.
http://www.theonion.com/articles/onion-twitter-password-chan...
I always remember this site for their Falso prover suite: http://www.inutile.ens.fr/estatis/falso/
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!
(Recommendations not to use your real password notwithstanding)
:\
http://www.intel.com/content/dam/www/public/us/en/apps/passw...
The fact that they don't send the password just means that a MITM needs to put in slightly more work.
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...
This site would be much better if it took the time to "crack" the password you submitted.
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...
It is an inherently inaccurate probabilistic estimation of an attacker's methods, and does make any claim of being more than that.
Both are randomly selected 12-letter dictionary words (from /usr/share/dict/words on Ubuntu, excluding words with uppercase letters or punctuation).
Or you know, better yet, just don't type your real password into it.
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.
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.
Come at me bros.