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

Xkcd Password Generator

preshing.com

Post reply on HN
Print view View original

191–200 of 299 posts

Re: Xkcd Password Generator

#191

Post by [deleted] »

mortenjorck wrote: post #139
ddlatham wrote: post #23

A lot of comments here seem to be missing the point. The main point is to use passwords that give you the most "bang for the buck" in the sense of adding the most bits of entropy for the least difficulty of remembering. Adding an extra number, or punctuation, or certain numbers of repetitions generally adds only a little bit of entropy for a significant cost in additional challenge to your memory. Our minds are well…

I've started using song lyrics when given the option of an extra-long password. I can get a very long string with little effort, and it's trivial to remember. The best part is that any automated attack would have to deal with ringtone popups.

[deleted]

Re: Xkcd Password Generator

#192

Post by eru »

bnegreve wrote: post #109
eru wrote: post #98

Earlier quoted context omitted.

If you allow multiple occurrences of the same word, you can get slightly higher entropy while making the passwords potentially even easier to remember. echo $(for i in 1 2 3 4; do shuf -n1 /usr/share/dict/words; done) (Sorry, I'm not very good at bash, so this loop is probably not idiomatic.)

for i in `seq 1 4`; :)

Thanks. By the way, $(seq 4) is enough.

Re: Xkcd Password Generator

#193

Post by abalone »

This scheme could be easily guessed by a dictionary attack that simply ran through combinations of dictionary words instead of individual characters.

If this became a popular scheme, the whole entropy argument goes out the door. It only has more entropy if we compare the two schemes on a character-by-character basis (~10 vs. ~25). Of course the longer string will appear to have more entropy.

But if a password guesser expects the pattern of the "four common words" scheme, as they might if it became popular, it's not nearly as entropic. A better comparison would be to consider each word as a single "character" from a 180,000 sized alphabet (for an English dictionary).

Calculate the entropy of that and you'll find it's in the same ballpark.

Re: Xkcd Password Generator

#195

Post by marze »

Isn't this discussion premised on a server configured to allow fast password guessing indefinitely?

This is 2011, shouldn't every server be configured to allow a guess every two seconds for 20 guesses, then every 10 minutes, or something similar?

I'm not familiar with common practices in this area, but why wouldn't all such services be configured to limit the incorrect guesses?

Re: Xkcd Password Generator

#196

Post by ry0ohki »

marze wrote: post #195

Isn't this discussion premised on a server configured to allow fast password guessing indefinitely? This is 2011, shouldn't every server be configured to allow a guess every two seconds for 20 guesses, then every 10 minutes, or something similar? I'm not familiar with common practices in this area, but why wouldn't all such services be configured to limit the incorrect guesses?

Most really strong systems lock an account after a couple of incorrect guesses. I assume this is all for systems that may not be secured to prevent brute force.

Re: Xkcd Password Generator

#197

Post by glenra »

bryanlarsen wrote: post #150
Lexarius wrote: post #62

Earlier quoted context omitted.

This is why, for my lab's password changer, the requirement for short passwords is simply that it must have one upper, one lower, one digit, and one none-of-the-above (and be at least 8 characters). If you have a long password (at least 16 characters), all other requirements are waived so that you can use passphrases.

The requirement for many of my website is simply that it "must not consist solely of lowercase letters". (as well as a minimum length).

>must not consist solely of lowercase letters

Which is exactly the sort of terrible restriction xkcd is criticizing.

Re: Xkcd Password Generator

#198

Post by gjm11 »

nikcub wrote: post #167
gjm11 wrote: post #161

Earlier quoted context omitted.

DANGER: This gives no more entropy than what srand() uses, which (at least for GNU awk) is simply the current UNIX time, which (if we assume that when you generated the password is known to within one year) means only about 25 bits of entropy.

srand in awk is platform specific. on most recent is isn't a straight call to srand(). I have another version that I use that stuffs srand but in the end I figured srand from a 250k dictionary is still better than picking words out of your head from a ~1k dictionary

I looked at the trunk code for gawk on Savannah when I wrote the above. It passes the output of time(0) straight into srand().

The size of the dictionary doesn't matter (given that it's more than about 70 words); the limiting factor is the entropy in the RNG seeding.

Re: Xkcd Password Generator

#199

Post by Dove »

bryanlarsen wrote: post #150
Lexarius wrote: post #62

Earlier quoted context omitted.

This is why, for my lab's password changer, the requirement for short passwords is simply that it must have one upper, one lower, one digit, and one none-of-the-above (and be at least 8 characters). If you have a long password (at least 16 characters), all other requirements are waived so that you can use passphrases.

The requirement for many of my website is simply that it "must not consist solely of lowercase letters". (as well as a minimum length).

Yeah, a lot of my passwords look like "securesecretpassphraseA1!"

There's the secure piece, and there's the obeisance to the stupid website piece.

Re: Xkcd Password Generator

#200

Post by mtogo »

ry0ohki wrote: post #196
marze wrote: post #195

Isn't this discussion premised on a server configured to allow fast password guessing indefinitely? This is 2011, shouldn't every server be configured to allow a guess every two seconds for 20 guesses, then every 10 minutes, or something similar? I'm not familiar with common practices in this area, but why wouldn't all such services be configured to limit the incorrect guesses?

Most really strong systems lock an account after a couple of incorrect guesses. I assume this is all for systems that may not be secured to prevent brute force.

Locking the account is the wrong way to go about it since it makes DoS on known accounts trivial.

Blocking the IP or an increasing time between tries is, afaik, the "right way".

Post reply on HN