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

Hacker, Hack Thyself

blog.codinghorror.com

Post reply on HN
Print view View original

41–50 of 114 posts

Re: Hacker, Hack Thyself

#41

Post by Ajedi32 »

SamBam wrote: post #39
Ajedi32 wrote: post #35

Earlier quoted context omitted.

zxcvbn accounts for the use of word lists. (And keyboard patterns, and common dates, and repeated characters, and a dozen or so other common patterns you probably haven't thought of yet.) Try it yourself: https://dl.dropboxusercontent.com/u/209/zxcvbn/test/index.ht... And in fact, four random words is actually quite strong. The XKCD comic that password is taken from accounts for the use of word lists in its entropy c…

By `correctbatteryhorsestaple` I meant exactly that. Four words are great. THOSE four words would be terrible.

But a brute force test like the parent comment described wouldn't catch that either, unless it had 'correctbatteryhorsestaple' as a word in one of its dictionaries. And if you're going to go that route, it's just as easy to put 'correctbatteryhorsestaple' in one of zxcvbn's dictionaries.

Any common password pattern you could catch via brute force could also be detected via zxcvbn, except that zxcvbn would be much faster and more efficient at it.

Re: Hacker, Hack Thyself

#42

Post by schoen »

SamBam wrote: post #32
Ajedi32 wrote: post #31

Earlier quoted context omitted.

That's a cool idea, but wouldn't it be more efficient to use something like zxcvbn to estimate the strength of new passwords and reject weak ones? That way you're not wasting electricity running a GPU array at full tilt 24/7.

It might not catch the kinds of things that seem strong but end up on word lists. `correctbatteryhorsestaple`, and even more so `correctbatteryhorsestaple1` or `correctbatteryhorsestaple!` would probably pass a "strength" test with flying colors, but you bet it would get cracked in a moment by any script kiddie with a word list.

This also shows that measurements of entropy are always relative to a particular party's knowledge, which is an interesting concept. (When we say that we're measuring the uncertainty that an attacker -- or message recipient -- has, that naturally depends on what the attacker or message recipient knows.)

Re: Hacker, Hack Thyself

#43

Post by SamBam »

Ajedi32 wrote: post #41
SamBam wrote: post #39

Earlier quoted context omitted.

By `correctbatteryhorsestaple` I meant exactly that. Four words are great. THOSE four words would be terrible.

But a brute force test like the parent comment described wouldn't catch that either, unless it had 'correctbatteryhorsestaple' as a word in one of its dictionaries. And if you're going to go that route, it's just as easy to put 'correctbatteryhorsestaple' in one of zxcvbn's dictionaries. Any common password pattern you could catch via brute force could also be detected via zxcvbn, except that zxcvbn would be much fas…

Yes, the info I was missing, which you provided in your first reply, was that zxcvbn does use word lists. I should have acknowledged that in my reply, thank you.

Re: Hacker, Hack Thyself

#44

Post by Ajedi32 »

schoen wrote: post #42
SamBam wrote: post #32

Earlier quoted context omitted.

It might not catch the kinds of things that seem strong but end up on word lists. `correctbatteryhorsestaple`, and even more so `correctbatteryhorsestaple1` or `correctbatteryhorsestaple!` would probably pass a "strength" test with flying colors, but you bet it would get cracked in a moment by any script kiddie with a word list.

This also shows that measurements of entropy are always relative to a particular party's knowledge, which is an interesting concept. (When we say that we're measuring the uncertainty that an attacker -- or message recipient -- has, that naturally depends on what the attacker or message recipient knows.)

Usually in entropy estimates you assume the attacker has full knowledge of the password generation method used. (Kerckhoff's principle.) In reality, most attackers won't know what generation method you used, but it's better not to rely on security by obscurity when it comes to passwords.

Re: Hacker, Hack Thyself

#45

Post by gwern »

infogulch wrote: post #36
proaralyst wrote: post #4

Earlier quoted context omitted.

Which they already do; from the post: > Users cannot use any password matching a blacklist of the 10,000 most commonly used passwords.

My question is, is 10k good enough? Wouldn't it be better to check against more? 50k?

Presumably more is always better, but there's a very long tail of passwords so the hit rate will drop off a cliff, and now you're storing 5x as much data for increasingly questionable benefit.

Re: Hacker, Hack Thyself

#46

Post by whoami_nr »

I am not an expert on password hashing but I was wondering why can't the websites hash their passwords twice using two different hash algorithms. That way when the hashes are exposed, the attackers have to go through two algorithms. Is the time complexity increase only marginal that people don't do this ?

Re: Hacker, Hack Thyself

#47

Post by adamkruszewski »

mike-cardwell wrote: post #37
kqr wrote: post #21

Earlier quoted context omitted.

Interesting! Did you consider regularly sending phishing emails yourself, and automatically call out anyone who reply anything at all to them? I mean, you won't catch quite as many people, but eventually most will learn, one would think.

I do remember that idea being discussed. I can't remember why we didn't go ahead with it at the time.

Wouldn't that add additional noise to each employee work and thus could potentially be more costly than phishing e-mails themselves?

Re: Hacker, Hack Thyself

#48

Post by a_imho »

peterclary wrote: post #18

Encrypting the hashes in the database would make it safer. That way the password hashes can't be attacked in this way unless they can decrypt them first.

Is this method used/recommended? What could be the drawbacks?

Re: Hacker, Hack Thyself

#50

Post by raesene9 »

whoami_nr wrote: post #46

I am not an expert on password hashing but I was wondering why can't the websites hash their passwords twice using two different hash algorithms. That way when the hashes are exposed, the attackers have to go through two algorithms. Is the time complexity increase only marginal that people don't do this ?

Instead of the added complexity of implementing multiple hash algorithms, if you're using something like bcrypt or PBKDF2 you can just increase the work-factor which makes the attacker (or indeed your application) do more work to calculate the hash.

There's a risk, depending on your usecase and traffic levels that if you crank work factors too high, you can impact the users perception of your performance (e.g. a login operation might appear slow)

Post reply on HN