Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Zxcvbn: realistic password strength estimation

tech.dropbox.com

Post reply on HN
Print view View original

71–80 of 134 posts

Re: Zxcvbn: realistic password strength estimation

#71

Post by tomp »

Lagged2Death wrote: post #28

I'm surprised to see that "correct horse battery staple" type pass-phrases really have to be quite 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. I wonder if that's because email address…

In general, email addresses should make quite good passwords (two.words@domain.tld). However, limiting yourself to yourname.yoursurname@yahoo/google.com reduces the entropy a lot.

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

Re: Zxcvbn: realistic password strength estimation

#72

Post by comex »

eblume wrote: post #61
wh-uws wrote: post #39

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) 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 nice touch

For the lazy, if you enter "correcthorsebatterystaple" the password strength gets set to "lol" with an info-box that reads something along the lines of "Don't take the webcomic too seriously. :)"

...but, oddly enough, not "correct horse battery staple" (at least, that's how I'm used to writing passphrases; I guess the comic could be interpreted either way.)

Re: Zxcvbn: realistic password strength estimation

#73

Post by aidenn0 »

16s wrote: 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.

My solution so far is:

  cat /dev/urandom|base64|tr -d '/+'|head -c10
Nearly every site supports a-z,A-Z,0-9 at 10 characters

Re: Zxcvbn: realistic password strength estimation

#74

Post by brownbat »

16s wrote: 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.

My biggest pet peeve is how no one explains their password constraints until you break one of them.

Re: Zxcvbn: realistic password strength estimation

#77

Post by brownbat »

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.

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

Re: Zxcvbn: realistic password strength estimation

#78

Post by jstalin »

aidenn0 wrote: post #73
16s wrote: 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.

My solution so far is: cat /dev/urandom|base64|tr -d '/+'|head -c10 Nearly every site supports a-z,A-Z,0-9 at 10 characters

10-character apha-numeric password is crackable in a matter of days: http://whitepixel.zorinaq.com/

Re: Zxcvbn: realistic password strength estimation

#79

Post by Game_Ender »

jstalin wrote: post #78
aidenn0 wrote: post #73

Earlier quoted context omitted.

My solution so far is: cat /dev/urandom|base64|tr -d '/+'|head -c10 Nearly every site supports a-z,A-Z,0-9 at 10 characters

10-character apha-numeric password is crackable in a matter of days: http://whitepixel.zorinaq.com/

Does that break more then md5? I thought it was well known that md5 was a bad password hash algorithm.

Re: Zxcvbn: realistic password strength estimation

#80

Post by aidenn0 »

drostie wrote: post #46
blake8086 wrote: post #5

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

That's probably the wrong way to think about it, and might -- as it does in this case -- lead to a ridiculously oversized password-guessing implementation which tries to do too much fancy business. 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. T…

I thought of and tried this already.

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.

Post reply on HN