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

121–130 of 134 posts

Re: Zxcvbn: realistic password strength estimation

#121

Post by vog »

ch0wn wrote: post #112
chimeracoder wrote: post #89

Earlier quoted context omitted.

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

This is exactly what my bank requires. Worst part after I told them that this is irresponsible: A few years ago they only allowed a 5-digit PIN for their web login .

That's okay as long as the account is inactivated after 3 failed login attempts. Which is, of course, only sensible for banks which have local branches where you can re-activate your account.

For a pure online bank this would be irresponsible, indeed.

Re: Zxcvbn: realistic password strength estimation

#122

Post by vog »

idupree wrote: post #107
elithrar wrote: post #87

Earlier quoted context omitted.

> It always bothers me a bit when I see analysis of password strength for compromised sites without any mention of the possibility that the account might just not be important to users. 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.

Recently I made a new password for some random site (and keep an encrypted record of it). Then I was relieved I did, because the site turned around and emailed the password right back to me. Unencrypted. In plaintext. 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-in…

Many mailing lists are doing that by default, too.

Re: Zxcvbn: realistic password strength estimation

#123

Post by tete »

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.

Same is true for diceware passwords, because they are in a dictionary.

http://world.std.com/~reinhold/diceware.html

Re: Zxcvbn: realistic password strength estimation

#124

Post by tete »

midnight_city wrote: post #118
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.

I recommend PwdHash [ https://www.pwdhash.com/ ]. It has extensions for Chrome, Firefox, and Opera, and I have not yet had a site complain about its generated passwords. zxcvbn assigned my generated password for their site a crack time of ~21 million years.

Similar to PasswordMaker I guess?

http://passwordmaker.org/

It offers lots of nice-to-have options.

Re: Zxcvbn: realistic password strength estimation

#125

Post by bluecalm »

jstalin wrote: post #88
Game_Ender wrote: post #79

Earlier quoted context omitted.

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

I don't know why an application couldn't also attack other hashing algorithms. It's just about brute force creating lots of hashes. This app also uses GPUs to brute force TrueCrypt: http://www.golubev.com/igprs/

Hash functions are designed to be fast, to use them in stuff like hash tables, hash structures, checksums etc when the faster the function the better (as long as it doesn't have too many collisions). If you transfer data fast and need a lot of checksums or if you do operations on hash structures your goal is speed. On the other hand with passwords you don't want hash, you want encryption and preferably encryption which is very difficult to calculate as encrypting passwords is rare operation and could take those extra CPU cycles for normal use but which is crucial to make it difficult to crack by brute force.

See: http://en.wikipedia.org/wiki/Cryptographic_hash_function

Using hash instead of encryption for passwords is major security mistake

Re: Zxcvbn: realistic password strength estimation

#127

Post by mokus »

nosignal wrote: post #91
Splines wrote: post #20

I think it's interesting that "correcthorsebatterystapl" is more secure than "correcthorsebatterystaple". Makes sense, but it's amusing to see the time drop as you add letters.

I noticed this too. It seems advice to "pick random words" should be extended to "pick random words and leave the last letter off".

That only doubles the size of the attacker's dictionary, though. Instead, I'd say "pick random words and add a few random typos". As long as there aren't too many the typos will be as memorable as the words themselves (more so if you're a spelling pedant like me), and using a variety of typos instead of just one simple transformation increases the search space a lot more.

Re: Zxcvbn: realistic password strength estimation

#128

Post by chimeracoder »

vog wrote: post #121
ch0wn wrote: post #112

Earlier quoted context omitted.

This is exactly what my bank requires. Worst part after I told them that this is irresponsible: A few years ago they only allowed a 5-digit PIN for their web login .

That's okay as long as the account is inactivated after 3 failed login attempts. Which is, of course, only sensible for banks which have local branches where you can re-activate your account. For a pure online bank this would be irresponsible, indeed.

It's not even okay then. If I know that the universe of possible passwords is so small, it's possible to use that to allow me to crack the encryption much more easily (for example).

Re: Zxcvbn: realistic password strength estimation

#129

Post by Aloisius »

masonhensley wrote: post #58
bo1024 wrote: 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…

Instead of banning them, it should simply inform the user:

"Your password is used by 1.2 million other people and can be easily guessed"

Post reply on HN