Live data from Hacker News

Password Requirements: Myths and Madness

franzoni.eu

21–30 of 257 posts

Re: Password Requirements: Myths and Madness

#21

yep, most of the discussion about passwords completely miss the point. a random word, like "dog" or "pingpong" is fine if the pqsswords are salted and hashed appropriately. how often have your accounts been hacked this way? if an adversary is really banging on the hash, and they want it, any password under around 50 characters is as good as "dog", and no "complexity" meter is gona cut it. that xkcd comic that says 55…

> yep, most of the discussion about passwords completely miss the point. a random word, like "dog" or "pingpong" is fine if the pqsswords are salted and hashed appropriately. how often have your accounts been hacked this way?

A word like "dog" or "pingpong" is favored in a rainbow-table type of attack. Nobody pre-hashes "109231oijoasdfnaisdfabatteryhorse123".

And yes many passwords have been hacked this way [0].

[0] - https://www.linkedin.com/pulse/linkedin-hack-understanding-w...

So it's hard to understand the point you are tried to make. Why don't you try again and expand on "modern brute force techniques" that could crack a password 50 characters long? More productive endeavor and benefits the board.

Re: Password Requirements: Myths and Madness

#22
post #12

> A short password is easy to bruteforce. But, a website should aim at password strength, not at password length. Is there a standard metric for “strength” though? I built my own random password generator and considered adding a strength meter but all of the functions I could find online seemed like they had pretty arbitrary logic. Length is probably the most objective proxy for strength.

Check out https://www.grc.com/haystack.htm

This particular tool is misleading at best. It counts only characters, and so misleadingly overrates passwords which are strings of words.

Compare it with this one, which actually identifies words and other patterns, for a more accurate guess of the search space: https://www.bennish.net/password-strength-checker/

Re: Password Requirements: Myths and Madness

#23

Earlier quoted context omitted.

im sorry, what point are you making? if its that "dog" is a weak password, i thought that was evident. but many people seem confused that "horseloverwhatever" is more secure, similarly that "dog23!Wog" is more secure. my point is they are equally trash so leave the user alone

short passwords are still a security weakness even when properly stored because the time necessary to brute force them is relatively low.

also: rainbow tables

Re: Password Requirements: Myths and Madness

#25

Earlier quoted context omitted.

im sorry, what point are you making? if its that "dog" is a weak password, i thought that was evident. but many people seem confused that "horseloverwhatever" is more secure, similarly that "dog23!Wog" is more secure. my point is they are equally trash so leave the user alone

short passwords are still a security weakness even when properly stored because the time necessary to brute force them is relatively low.

i agree. but most sites that enforce a policy (8 chars, symbols, etc) are bruted just as easily. we need to take a step, away from passwords, to secure against brute force in 2022

Re: Password Requirements: Myths and Madness

#26

My favorite is this transaction: I forgot my password. Can you send me a link? Sure, here you go. Pick a new password. Okay, CorrectHorseBatteryStaple. Sorry, you can't use an old password

Funny, sure. But you still can have the same transaction by hashing "CorrectHorseBatteryStaple" then comparing with the stored hash.

Re: Password Requirements: Myths and Madness

#27

Earlier quoted context omitted.

short passwords are still a security weakness even when properly stored because the time necessary to brute force them is relatively low.

also: rainbow tables

The length of the password only somewhat matters for rainbow tables -- they're not limited to dog-sized passwords -- but also, I rarely come across implementations these days that do not use a salt of some kind, which defeats existing rainbow tables. Generating one-off tables is about as expensive as just cracking the hashes directly.

(Then again, the implementations I see are mostly from well-known projects or customers that care enough about security to hire us. It's biased, but I do think word has gotten round about hashing and salting.)

Re: Password Requirements: Myths and Madness

#28
post #20

Earlier quoted context omitted.

im sorry, what point are you making? if its that "dog" is a weak password, i thought that was evident. but many people seem confused that "horseloverwhatever" is more secure, similarly that "dog23!Wog" is more secure. my point is they are equally trash so leave the user alone

> if its that "dog" is a weak password, i thought that was evident You're confusing me. First you say that "dog" is just as strong as any other password, now you say that it should have been evident that it's a weak password. Which is it? > my point is they are equally trash This again sounds contradictory, but this time within one comment. First you say that horseloverwhatever is stronger than dog, but then that the…

i meant others commonly assume horseloverwhatever is more secure.

to be more clear,

1. dog is weak 2. horseloverwhatever is weak 3. 8randoms! is weak 4. therefore, dog is as good as horseloverwhatever or 8randoms! 5. most account compromises do not even require a brute force (shoddy practices on the backend) making the complexity requirements pointlessly burdensome on the user 6. in cases where you want a password to resist a legitimate brute force, we need to talk about passphrases (ie > 50 chars) or passwordless

what u think?

Re: Password Requirements: Myths and Madness

#29
post #13

> A short password is easy to bruteforce. But, a website should aim at password strength, not at password length. If it is "easy to bruteforce" (guess without any prior knowledge), then it is not "strong". > If I use four unicode code points outside the [multi-language characters table], my password is probably very safe already. Security through obscurity. This is safe until everyone does it. It's not a strong passw…

> > If I use four unicode code points outside the [multi-language characters table], my password is probably very safe already.

> Security through obscurity. This is safe until everyone does it. It's not a strong password by virtue of being short, it's strong because this is impossible to input and so nobody uses it and so it doesn't make sense to guess. But you bet that if you ever log into a compromised system, use a phishing page, or a site stores and loses your password in plain text, the gig is up and it's known that cracking u/alanfranz's passwords is a matter of trying a few random unicode characters instead of letters.

This is plain wrong. The Basic Multilingual Plane consists of 65536 most commonly used codepoints. If your password contains a character outside of the BMP (e.g. an emoji), the attacker has to be bruteforcing over at least one other plane in addition to the BMP, which is 2*65536 characters = 17 bits of entropy per character. 4*17 = 68 bits of entropy is plenty. Even if everyone included an emoji in their passwords, this won't become any weaker.

Re: Password Requirements: Myths and Madness

#30
post #13

> A short password is easy to bruteforce. But, a website should aim at password strength, not at password length. If it is "easy to bruteforce" (guess without any prior knowledge), then it is not "strong". > If I use four unicode code points outside the [multi-language characters table], my password is probably very safe already. Security through obscurity. This is safe until everyone does it. It's not a strong passw…

The author's point is not that you should use a short unicode password, but that the key thing to focus on is password strength, not length. That is, use a lib that enforces password strength -- he is arguing -- instead of focusing on arbitrary and possibly wrong constraints such as "password too short". Strength is going to take care of it if it really is too short, anyway.

The author is also aware that we've known these things for a long time now -- he opens his article by complaining about this and how slow some websites and apps are at catching up, in fact.

Post reply on HN