Live data from Hacker News

Zxcvbn: realistic password strength estimation

tech.dropbox.com

51–60 of 134 posts

Re: Zxcvbn: realistic password strength estimation

#51

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?

Combinatorics. Yes.

Re: Zxcvbn: realistic password strength estimation

#52

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.

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.

They already blame the bank and the internet when they have to change their password after every login because you've forced them to set it to something completely non memorable.

Re: Zxcvbn: realistic password strength estimation

#53
post #37

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: 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.

Whenever I come across a site that refuses to let me sign up with a secure password, I either leave right away or send them a short mail first.

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

#54
post #18

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. 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

Re: Zxcvbn: realistic password strength estimation

#55
post #4

The 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. :-)

I actually had a problem with this at a web dev job I did, where I wanted a JS entropy estimator and coded one in maybe half an hour (though it was a bit of unexpected time to debug it). Mine was considerably simpler than the above and would basically use lg(character class size) * length, but would notice when you switched character classes, too. So it was expecting, for example, numbers at the end of the file and would only reward you entropy(letters) + entropy(numbers).

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

#56

Earlier 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.

If you aren't German and can't log in, discovering such combos is a bit difficult. Once I figured it out, no problem.

Re: Zxcvbn: realistic password strength estimation

#57
post #51

Earlier quoted context omitted.

Also, pas sw ord Will apparently take centuries to crack. I see the reasoning, but can this be correct?

Combinatorics. Yes.

Well, no. In "password" you have one common word -- let's say 1,000 options, 2^10. You have two spaces which can go in any of 9 places, for 9 * 8 / 2 = 36 different places, plus I suppose the 1 and 9 for zero and one places.

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

#58
post #33

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.

But would that decrease your conversion rate for your site/ application?

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

#59

Earlier 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_...

Guess = अनुमान , अंदाज़ , अटकल

Re: Zxcvbn: realistic password strength estimation

#60
post #54
post #18

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. 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

Apparently one of my throwaways is secure nearly until the heat death of the universe.

2.1123066418521704e+73 years to crack

Post reply on HN