"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?
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.)
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.
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.
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.
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?
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.
> 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.
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
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.
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.
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?
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.
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)
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 ;)
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.
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.
> 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.
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.
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 :-)
59 comments
[ 4.2 ms ] story [ 108 ms ] threadAlso, "Password" as a part of an example password? "Append a special character"? What is this, 1995?
Nice idea with the entropy checker, though.
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.)
In general, including the spaces is a better idea, because 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.
EDIT: This video explains it: 10 hidden cameras. http://www.intel.com/content/www/us/en/security/passwordwin-...
I think we trust it primarily because it's client side code and on Intel's site.
"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
For comparison, here is the best password checker I've found:
http://dl.dropboxusercontent.com/u/209/zxcvbn/test/index.htm...
(I am very impressed by the password checker though; it's difficult to cover all scenarios)
> "i like pepper": 9 hours
Well that's clearly because salted passwords are more secure.
"salt tastes ok": 324658 years
"intel password sweepstakes": 8441109 years
"dictionary attack": 390 years
CONGRATULATIONS! It would take about Infinity years to crack your password.
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
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.
Your first password, they interpret as aa! Your second, a!a Your third, a1!23456 Your fourth, a!bcdefga
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.
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.
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.
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!
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.
"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!
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)
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.
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.
http://pwdhash.com
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.
Bueno.
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.
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...
"realistic password strength estimation" https://tech.dropbox.com/2012/04/zxcvbn-realistic-password-s...
(No, that's not a phishing page)