So I make a different password and the sites say it is too weak as it has no special chars or uppercase chars:
So I give up and type Password1 which is normally accepted.
There were times where I had to rely on password managers too, though. Banking sites are one common place ...
I can't tell you the number of times I've tried to explain to banks that 'security questions' are absolutely worthless, and that their 'secure password' policy is actually worse than no policy at all.
One bank actually requires passwords to be between 6 and 8 characters in length, with at least one letter and one number and no special characters.
What the fuck.
For a pure online bank this would be irresponsible, indeed.
cat /dev/urandom|base64|tr -d '/+'|head -c10
I think the assumption here is that the password isn't an MD5 hash, but instead something a little more resilient. If it's MD5, you're probably screwed anyway.
This app also uses GPUs to brute force TrueCrypt: http://www.golubev.com/igprs/
Using hash instead of encryption for passwords is major security mistake
zxcvbn assigned my generated password for their site a crack time of ~21 million years.
It offers lots of nice-to-have options.
Looks unbelievable at first. How could people be so stupid?
But I use such passwords all the time. I use a variety of websites where I have no need or desire for security. Want to post burrito reviews on burritophile.com as me? I picked something simple and easy to guess, a couple hours and you'll be going to town! (Just promise not to badmouth the Cosmic Cantina.)
My bank accounts? Oops, didn't use the same password.
But there is a caveat. If the account is somehow identifiable as yours (say, because your friends know it's your account) then suddenly it's a possible social attack vector. Perhaps a weak one, but probably not something to be ignored, either.
I actually use that as a factor when considering a password. If I think the site isn't going to be the most secure (a phpBB forum, or hand-rolled web-app), then I'm more likely to use a simple (but still relatively decent) password.
Hmm, that is wrong enough that I'll call them out by name... https://www.nbotickets.com/
(Is it polite and useful to email them how I feel about that? I feel like I'd just be "someone-is-wrong-on-the-internet"-ing. Advice?)
Every time I'm forced to have a password with 3 or 4 character classes I sigh and think of that xkcd comic
Edit: also try typing the password from the xkcd comic here https://www.dropbox.com/register
So a better message might be:
"Don't follow the webcomic too closely. :)"
Rendering it about as useless as 123456789 in this instance
I wonder if that's because email addresses are really hard to crack or if it's because the rules of this scoring system weren't designed to account for such a practice. Not a practice of using your real email address as a password, but the practice of using a fictional email address as a password.
Also, the idea of passwords are easy-to-remember&hard-to-guess. The only emails easy to remember are the one's you're using currently, which shouldn't be to hard for an attacker to figure out (in general).
Easy to remember yet hard to guess. (Unless you read this comment)
PS: Although I don't remember the exact words but there were some which are strikingly similar in both languages. But I found this for you. http://en.wikipedia.org/wiki/List_of_English_words_of_Hindi_...
(Since someone will ask, yes, there are some accounts I'm willing to limit myself to using one of my personal computers to access, or jumping through significant hoops to get there, like my bank account.)
password: This is easy to guess
crack time (seconds): 246474312966
crack time (display): centuries
score from 0 to 4: 4
Then you can automatically skip any password you know is too simple, because the site won't have allowed the user to set it in the first place. You could also de-weight any constructions your generator is using (keyboard locality, l33t, ..), rather than positively weighting them as is done now.
Intuitively, it seems like the more restrictions placed on a password (must have 1 x char, no more than 20 total chars, ...), the smaller the entire search space. But where is the inflexion point where these rules generate stronger passwords than they assist.
Then again, if you're doing your hashing and storage right, brute force ain't gonna help.
40 bits of entropy means 2^40; 20 bits means 2^20. 2^40 - 2^20 gives you something very, very close to 2^40 (39.9999986 bits of entropy.)
Makes sense, but it's amusing to see the time drop as you add letters.
Can anyone elaborate why "&" or "!" wouldn't be allowed?
There probably is a special level of hell for UI UX sins.
Password fields that are too short cause a similar problem, where you ask "am i still typing? did it cut me off?"
We purposely made the fields huge to help with this on:
the forbidden list is:
$ < > ^ ! [ ]
The exclamation mark is weirder -- I can't think of a deep need to escape that symbol. The + symbol, maybe, since sometimes + in a URL is supposed to be used as a replacement for %20 as an encoding for a space, but not the ! symbol.
The one usability problem I see is users complaining that zxcvbn is calling their 'secure' password they use on everything insecure. :-)
It was at least a disaster when it hit the management who were doubling at the time as user testing -- "this should be a secure password and it's not!" applied to passwords which didn't sound very secure at the time. This was fixed by reducing the entropy bounds to be regarded as "safe" or not. (The result was that "password1" became a "strong" password, if memory serves me correctly.)
Before that, I got another interesting gripe from one of my dev colleagues: "'aaaaaaaaaa' [10 a's] is not secure, but 'aaaaaaaaaaa' [11 a's] is, wtf?!". I was reluctant to do anything more complicated as a waste of my time but there is a reasonable expectation that if you do something like this, you do it very well.
There is a line between gracefully telling your user their password could be better for their own security and irritating them enough to leave your site.
To be honest, while most everyone here knows more about password security, most of us that do not use a password manager probably have a couple simple go to passwords that we use to try out all the apps HN users dream up and share. (...and more secure passwords when needed)
"Your password is used by 1.2 million other people and can be easily guessed"
The important thing I found while testing this was that it was important to tell users why their password sucked. Often times, they'll just keep adding 1's to the end of their password until it's good enough. Let people know, "Your password is in a known list of passwords", rather than, "The entropy of your password is 0."
one quintillion ,
three hundred ninety four quadrillion ,
seven hundred seven trillion ,
thirty six billion ,
eight hundred fifty one million ,
four hundred thirty five thousand
 - 1394707036851435000 translated by http://www.webmath.com/_answer.php
2.1123066418521704e+73 years to crack
horsebattery -- 3 minutes
h orsebattery -- 8 years
ho rsebattery -- centuries
horseb attery -- 85 years
horsebat tery -- 54 years
abcde -- instant
a b c d e -- centuries
horsebattery vs 'h orsebattery', on the other hand, shows a clear flaw -- it doesn't tolerate misspellings up to a given edit distance. edit distance is tricky because efficient word segmentation gets much harder, especially w/ support for l33t substitutions.
'abcde' vs 'a b c d e' is tricky too. i could add special case for spaces only that would allow zxcvbn to recognize 'a b c d e' as a sequence, but it wouldn't cover 'a-b-c-d-e', 'a8b8c8d8e' etc.
pas sw ord
46,000 options for 15.5 bits of entropy, only. Even if we assume that there are thousands of different "strategies" by which passwords might be chosen, that only adds ~10ish bits or so, and doesn't bring it under the useful thresholds.
It seems like password strength basically boils down to:
1) imagine the space of all possible passwords
2) put them in order from most to least likely (123456 would be at the top, some giant 64 character random monster at the bottom)
3a) if you're malicious, use this list to begin cracking
3b) if you're securing something, use this list to measure strength
An ideal password strength measurer would simply return the approximate rank of your password.
The most obvious way to do password strength checking would not (I don't think) let you "use this list to begin cracking", but would instead estimate the Kolmogorov complexity of the password, as a proxy for its entropy.
That sounds daunting, but it's actually pretty simple in principle: append the password to a couple concatenated dictionaries plus popular password files, and see how much it compresses with your favorite zipping algorithm. Compare it to how much 'password1' zips, because you know that's the first one that they try and therefore it has complexity 2^0. If the zipping algorithm is good, it will automatically figure out most of these tricks directly from the 'bad password lists'.
I would say a little more: it is probably the case that you can "steal" the dictionary from one zipping and force a zipping algorithm to use that dictionary. If this is the case, the dictionary needed reduces to 64 KiB (I believe) rather than the 600 KB that the above script requires. I don't know how much effort it takes to get zlib-with-a-static-preset running in JS but then again, I don't know how much time it took zxcvbn to reach its final form either.
Using /usr/share/dict/american-english for my dictionary is a bit crap because it does not yet speak l33t, but my dictionary can be used for "correcthorsebatterystaple". XKCD estimates 44 bits = 5.5 bytes; gzip --best estimates 7 bytes, maybe more if we had more sequences ending in '1' to better compress 'password1'. (Some extra bits are to be expected purely due to the diverse number of password-guessing algorithms; 'switch one character to l33t, switch two characters to l33t, end with a number' offer a couple extra bits which XKCD ignores in order to establish a lower bound.)
gzip does a terrible job at this. Long passwords that are in the dictionary come out as much stronger than short passwords not in the dictionary. For example, correcthorsebatterystaple increased the size by much more than ablekindpagequite despite the former being in the dictionary verbatim and the latter not.
lzma does a much better job, but all implementations I could find like to pad things out to 4-byte boundaries giving you poor resolution.
Why would you add the layer of indirection of running a compression algorithm over something, when it has to measure the same thing you're trying to get at?
Given a character '1' at the beginning of a password, how likely is it that '2' is the next character? Compression tools answer this question, but then they go a different direction with the application of their answer.
Also, if your password guesser guesses anything but '123456' as its first guess, it's suboptimal, since that really is the most frequent password.
But more importantly password strength meters don't result in stronger passwords. I saw an analysis a couple of months ago (unfortunately I didn't save the link) where they found showing password strength to the user had no impact on the strength of the password used. People would pick a password and then stick with it regardless of strength advice.
A fun extension would be to recognize repeated chunks in addition to single characters.
Someone should RFC a common password API, so password lockers can query the password rules and set up a new account or change the password on an existing account in the background while I browse.
You might worry that this would increase the attack surface, or push people towards a single point of failure, but I think ending password reuse and simple passwords could make for a healthy net gain if you carefully designed the protocol with security in mind. (Throttling and preventing account enumeration would be two key issues, but they could be overcome.)
Likewise, if it's used with LastPass or 1Password style services, you face the problem of dealing with entering it. Though a desktop PC is fine for this, the best counter-examples are mobile devices.
LastPass on mobile:
1. Use app that needs a password.
2. Realize password is in LastPass. Exit app, find LastPass.
3. Open LastPass, and login.
4. Copy password.
5. Switch back to the other app.
6. Enter password.
This is so tedious that people are going to re-use some password just for the sake of not having to do the above every time.
My passwords are generated using HMAC_SHA256( global password, domain_name, salt ). My global passwords is a 7 words phrase, contains capitalization and 2 words that are not in the dictionary. Each password generated is unique for each website and reasonably long (settled on 32 chars).
This is not perfect but works well.
Related to your problem of usability ... I use Firefox on my mobile and through Firefox Sync I get all cookies synchronized from my laptop. Meaning that I am rarely required to enter passwords on my mobile.
After having two of my passwords leaked via app breakins, I now use a password manager and make sure even the most arb of sites share nothing, each password is strong, and my master password is first class. Sure there's still a risk. Much lower than before.
Dictionary building software can create lists of words with those common substitutions. (swapping uppercase for lowercase, or subbing certain numbers for letters, etc.) They can also add numbers to the words.
Ideally, use a good diceware phrase to secure a password safe. Then use the strong password generation features of that password safe to create all the other passwords you need.
(You can write the diceware passphrase down if you need to while you're learning it. Just treat it like high value currency, and destroy it when you've learnt the phrase.)
Access control is a problem waiting for an easier solution.
$^$^$^i = crack time 3 months
$^$^$^z = crack time 5 years
Should the result vary so widely given the arguably minor variation?
n log (c)
for a length-n password with symbol space c.
the huge difference in crack time is because zxcvbn is using c==33 (symbols only) for $^$^$^_ and c==59 (symbols + a-z) for $^$^$^z
$^$^$^i is in the middle -- 'i' is considered a dictionary match, the rest is c==59 bruteforce.
the bigger problem is $^$^$^ isn't recognized as a pattern, but i'm working on ways to improve bruteforce estimation too. good example!
notaword12 - 17 hours
notawrod123 - 22 minutes
With almost any not-word, really. The extra 12 is better than 123 somehow.
SpinRite was great. Spinrite stopped being any use sometime in the early 90s.
should take 20 hours to crack.
But just add a 'd' to the end, and crack time drops to:
Yahoooo (with 139 o's)