Earlier quoted context omitted.
Not to mention: horsebattery -- 3 minutes h orsebattery -- 8 years ho rsebattery -- centuries horseb attery -- 85 years horsebat tery -- 54 years Which at the very least is a little odd, even if the reason (breaking up the words into less word-like structures) is clear. Also: abcde -- instant a b c d e -- centuries
Also, pas sw ord Will apparently take centuries to crack. I see the reasoning, but can this be correct?
Zxcvbn: realistic password strength estimation
51–60 of 134 posts
Re: Zxcvbn: realistic password strength estimation
#52I 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.
But majority of their users most likely do not know the consequences of using an easy password. And then they would blame the bank and the Internet.
Re: Zxcvbn: realistic password strength estimation
#53Many 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: UTP+NnhabgHKx6 So I make a different password and the sites say it is too weak as it has no special chars or uppercase chars: 5133fe36785a6e01cac7a68c9c111afff5bb4821 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 ...
Re: Zxcvbn: realistic password strength estimation
#54I 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. http://files.jjcm.org/jspass/ The important thing I found while testing this was that it was important to tell users why their password sucked. Often times, they'll ju…
one quintillion ,
three hundred ninety four quadrillion ,
seven hundred seven trillion ,
thirty six billion ,
eight hundred fifty one million ,
four hundred thirty five thousand
years to crack.Good god.
[0] - 1394707036851435000 translated by http://www.webmath.com/_answer.php
Re: Zxcvbn: realistic password strength estimation
#55The demo at http://dl.dropbox.com/u/209/zxcvbn/test/index.html shows what's happening behind the scenes. 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.
Re: Zxcvbn: realistic password strength estimation
#56Earlier quoted context omitted.
This may not be their reason, but I used to have a password with @ in it. Then I went to Germany and discovered the keyboards there didn't have @ on them. That was a fun time.
You can usually type some easy combination (here it's Ctrl+Alt+2 or AltGr+2) to get it. It's not like Germans don't write email addresses.
Re: Zxcvbn: realistic password strength estimation
#57Earlier quoted context omitted.
Also, pas sw ord Will apparently take centuries to crack. I see the reasoning, but can this be correct?
Combinatorics. Yes.
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.
Re: Zxcvbn: realistic password strength estimation
#58Any 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.
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)
Re: Zxcvbn: realistic password strength estimation
#59Earlier quoted context omitted.
Did hindi take "guess" as a loanword or is that just a massive coincidence
Loan word. I can't remember the the Hindi word for "guess" right now. 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_...
Re: Zxcvbn: realistic password strength estimation
#60I 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. http://files.jjcm.org/jspass/ The important thing I found while testing this was that it was important to tell users why their password sucked. Often times, they'll ju…
I just tried my password in your service and here's what I got [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 years to crack. Good god. [0] - 1394707036851435000 translated by http://www.webmath.com/_answer.php
2.1123066418521704e+73 years to crack