Many sites won't accept my passwords (SHA1_Pass). They say that they are too long or have inappropriate chars or that they are not complex enough. Here's an example of inappropriate chars:<p>UTP+NnhabgHKx6<p>So I make a different password and the sites say it is too weak as it has no special chars or uppercase chars:<p>5133fe36785a6e01cac7a68c9c111afff5bb4821<p>So I give up and type Password1 which is normally accepted.
> One in nine people had a password in this top 500 list. These passwords include some real stumpers: password1, compaq, 7777777, merlin, rosebud.<p>Looks unbelievable at first. How could people be so stupid?<p>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.)<p>My bank accounts? Oops, didn't use the same password.
I have waited for this for so long. I'm glad someone finally took it up and and more importantly that its on a site as popular as dropbox. (this way hopefully the thinking will gain some traction)<p>Every time I'm forced to have a password with 3 or 4 character classes I sigh and think of that xkcd comic<p><i>Edit:</i> also try typing the password from the xkcd comic here <a href="https://www.dropbox.com/register" rel="nofollow">https://www.dropbox.com/register</a><p>nice touch
I'm surprised to see that "correct horse battery staple" type pass-phrases really have to be <i>quite</i> long to score well, but that even comically short email addresses ("dlk3@mit.edu") score very highly. In fact, it looks like my ever-so-clever words-and-numbers web passwords ("Happy314Day") are all terrible, but all my email addresses all make maximum strength 4-point passwords.<p>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.
The article mentions that non-English language support as a future improvement. Since the article is long that it's easy to miss this point and to put that in perspective how important that is here's an example:<p><pre><code> yehtohaasanhaiguesskarna
</code></pre>
That means "This is easy to guess" in Hindi transliteration. Only English support would say it will take "centuries" to guess. (<a href="http://dl.dropbox.com/u/209/zxcvbn/test/index.html" rel="nofollow">http://dl.dropbox.com/u/209/zxcvbn/test/index.html</a>)
If these sorts of 'strength checkers' become ubiquitous across enough places, I wonder how much value there will be in using reverse-engineered (most of these are in JS for UX latency reasons, right?) models of their strength testing as another parameter to your brute-forcing module.<p>Then you can automatically skip any password you know is <i>too</i> 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.<p>Intuitively, it seems like the more restrictions placed on a password (must have 1 <i>x</i> 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.<p>Then again, if you're doing your hashing and storage right, brute force ain't gonna help.
I think it's interesting that "correcthorsebatterystapl" is more secure than "correcthorsebatterystaple".<p>Makes sense, but it's amusing to see the time <i>drop</i> as you add letters.
> Bank of America doesn’t allow passwords over 20 characters, disallowing correcthorsebatterystaple. Passwords can contain some symbols, but not & or !, disallowing the other two passwords<p>Can anyone elaborate why "&" or "!" wouldn't be allowed?
The demo at <a href="http://dl.dropbox.com/u/209/zxcvbn/test/index.html" rel="nofollow">http://dl.dropbox.com/u/209/zxcvbn/test/index.html</a> shows what's happening behind the scenes.<p>The one usability problem I see is users complaining that zxcvbn is calling their 'secure' password they use on everything insecure. :-)
Any password strength estimator worthy of the name ought to hardcode a list of those 10,000 passwords and disallow any of them. Add in standard algorithms and you're probably doing pretty well.
I created something similar a while back to demonstrate what makes a password secure. It's drastically less sophisticated than this (I wrote it in an hour or so), but it has the same approach - evaluating a password by entropy, not random requirements.
<a href="http://files.jjcm.org/jspass/" rel="nofollow">http://files.jjcm.org/jspass/</a><p>The important thing I found while testing this was that it was important to tell users <i>why</i> 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."
It certainly needs a rule for putting spaces between the words. "correct horse battery staple" and "correcthorsebatterystable" should be treated as being approximately equal in strength.
This seems like a great step forward, but it's still a bunch of ad-hoc rules. While the ruleset is definitely well-put-together and fairly comprehensive, it still doesn't seem like the most accurate measure.<p>It seems like password strength basically boils down to:<p>1) imagine the space of all possible passwords<p>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)<p>3a) if you're malicious, use this list to begin cracking<p>3b) if you're securing something, use this list to measure strength<p>An ideal password strength measurer would simply return the approximate rank of your password.
It's not unlikely that "correcthorsebatterystaple" is in several password attack dictionaries now, so sites may be legitimately ranking it as a weak password.<p>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.
I use a password locker. The only downside is that it makes setting up new accounts or changing passwords on an existing account slightly harder, which decrease usability and security a bit respectively.<p>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.<p>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.)
The real problem with humans is that passwords are still hard to remember for multiple services. Doesn't matter if you have a secure password and it's used everywhere.<p>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.<p>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.<p>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.
Did anyone look at the linked site <a href="http://xato.net/passwords/more-top-worst-passwords" rel="nofollow">http://xato.net/passwords/more-top-worst-passwords</a>? I pulled his top 10k list, but it doesn't add up with his analysis. I get that the top 100 passwords only cover 14% of the accounts, not 40%. And the top 1000 passwords only cover 44%, not 91%. These numbers don't change his argument all that much, but I'm curious what I'm missing about the way he calculated his.
I hate when they won't let me use a password that's not "strong" enough. I picked my password, let me use it. I know the consequences of using an easy password.
I feel like this is a stupid question, but what is wrong with having your password be something like "p4ssw0rd"? eg: a dictionary word where a few of the letters are switched for numbers, and maybe even a symbol at the end ("p4ssw0rd$") are these terrible passwords for some reason?
$^$^$^_ = crack time 26 days<p>$^$^$^i = crack time 3 months<p>$^$^$^z = crack time 5 years<p>Should the result vary so widely given the arguably minor variation?
This is a really great step forward for password strength estimation. If the OSC could get going on it and add a bunch more patterns it could be a great solution. Perhaps I'll have time to work on some patterns.
Adding a digram or trigram model would be interesting, as having one of these could greatly reduce the crack time of an English sentence as compared to random English words.
FWIW, it looks like Google specifically rates correcthorsebatterystaple lower than similar passwords. I wonder if any of these websites have it in a dictionary?
Length beats entropy every time. Steve Gibson has covered this before.<p><a href="https://www.grc.com/haystack.htm" rel="nofollow">https://www.grc.com/haystack.htm</a>
This is great. I love how:<p>thisisastrongpasswor
should take 20 hours to crack.<p>But just add a 'd' to the end, and crack time drops to:
"instant"<p>Magnificent!