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

Password Requirements: Myths and Madness

franzoni.eu

Post reply on HN
Print view View original

141–150 of 257 posts

Re: Password Requirements: Myths and Madness

#141

Post by pontilanda »

Zamicol wrote: post #44

Passwords should just be random numbers, and services should provide a suggested password on the sign up pages. Here's a 128 bit password: CR4EOJ5ZYQRKCGQV4OLN2ZRFS. Better than all that is public key authentication.

Unfortunately there are so many ideas that will "never" gain ground. People are still stuck with the user/password paradigm and it will take some serious push to move to something like Passkeys, which is obviously the best if implemented correctly (i.e. provide a fallback when using a non-own device)

We need a push like it happened for HTTPS, which became widespread in less than a decade, but that basically means Google has to push for it.

Re: Password Requirements: Myths and Madness

#142

Post by alanfranz »

jamujamu wrote: post #84

There are only really two types of passwords: Passwords for online accounts and passwords used to encrypt things. Imagine the password for my Gmail is Watermelon45. Theory says that's super weak, but I'm not a watermelon farmer and I wasn't born in 1945 so nobody who knows me is ever going to guess it. I trust Google will effectively block against brute force attacks by rate limiting login attempts, and if Google is…

> Now if I encrypt my portable SSD with the same password that is a problem. It would be trivial to brute force.

Probably not so trivial. It's very likely (disclosure: I'd need to check, but I'd expect that to be true in 2022) that the actual encryption key of your storage is a randomly-generated key, which is then protected with your password and a very slow decryption algorithm, so that bruteforcing is not so fast. Still, single dictionary word + two ciphers won't be terribly hard to decrypt for a really interested party.

But the point is that such attack requires physical access to your device (unless some other network hack is performed), which is a kind of 2FA.

Re: Password Requirements: Myths and Madness

#143

Post by alanfranz »

lolinder wrote: post #40
lucb1e wrote: 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…

> Security through obscurity. This is safe until everyone does it. If he's actually randomly selecting from the entire set of valid Unicode characters, then theoretically his four character password has orders of magnitude more entropy than an eight character alphanumeric password. The problem is that from the website's perspective there's no way to know what set of characters the user is choosing between. They could…

> If he's actually randomly selecting from the entire set of valid Unicode characters, then theoretically his four character password has orders of magnitude more entropy than an eight character alphanumeric password.

Exactly.

> but more likely someone just thought they'd be cute and throw a few popular emoji at it

That's entirely possible.

Thanks, I'll update the article.

Re: Password Requirements: Myths and Madness

#144

Post by alanfranz »

lucb1e wrote: 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…

> Security through obscurity

It was a kind of joke. If you don't show the password, then it seems more secure because nobody can see it. I was in doubt whether to retain that naming.

Re: Password Requirements: Myths and Madness

#145

Post by alanfranz »

lolinder wrote: post #49
alwayslikethis wrote: post #29

Earlier quoted context omitted.

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

Correct, but the recommendation in the article is still wrong. If I get a password that has four Unicode characters in it, it's possible that it's a strong password that chose truly randomly from the available Unicode characters, but it's much more likely that someone just picked four that they like. In the latter case, the bits per character is going to be much lower, but I can't tell the difference just looking at…

The same problem can happen with eight-char passwords. I could pick the same eight chars I like all the time and reuse passwords. You cannot fix password reuse that way.

I'm not advocating for emoji passwords, it was just a discussion about password strength vs length.

Re: Password Requirements: Myths and Madness

#146

Post by pontilanda »

cirrus3 wrote: post #18

Password managers are "obviously" the solution - in my experience they generate good passwords that are accepted almost all the time now days. However, I still think 3rd-party password managers are too complex for many people, and those people are the ones who need them most. OS-level password management is a bit easier but not great. Browser native password managers are a terrible idea IMO, for people who can't hand…

The interoperability boat has sailed. macOS has had an open Keychain for decades and Google eventually dropped support for it. I don't see them suddenly going back, sharing efforts and allowing cross compatibility.

What we need is just passwords to come front and center anywhere they are: We need a Password.app that I can open and access all I need. Keychain Access was exactly that but its UI is stuck in 2000.

Re: Password Requirements: Myths and Madness

#147

Post by professorTuring »

I lead Security in a quite large bank. I love this article, I’ve been advocating for this line of thoughts for more time that I can remember.

I have spoken to regulators hundreds of times, over this and a bunch other security topics that are definitely obsolete. Security policies that just don’t make sense…

The most important thing for this kind of things to advance is to have the correct people in the correct places, and usually in this positions you have dinosaurs…

Re: Password Requirements: Myths and Madness

#148

Post by fragmede »

mijoharas wrote: post #87
MaxGabriel wrote: post #46

Earlier quoted context omitted.

You might be able to appeal to NIST standards, which now recommend against some of the bad practices like special characters.

We had a credit reporting agency (big US one, suffered a large data breach a few years ago) try and insist that we require password expiration for our employees. After pointing to the NIST standards (and two other references) saying that that reduced security and saying "we're not prepared to reduce our security" they backed off.

Mind sharing those two additional references, for those of us who're still forced to do password expiration?

Re: Password Requirements: Myths and Madness

#149

Post by gpderetta »

wizofaus wrote: post #118
TedDoesntTalk wrote: post #115

Earlier quoted context omitted.

> That's literally impossible without plaintext passwords No, it’s not. It’s called locality-sensitive hashing. You’d store the last 10 LSH hashes in a database next to the SHA-256 hashes. Compare those LSH hashes to the LSH hash of the new password. Match? Reject the new password. It’s also used to identify photos that are similar: https://en.m.wikipedia.org/wiki/Locality-sensitive_hashing

Surely even having an LSH stored is a potential compromise - e.g. if my password happens to have the same LSH as somebody else because I've used "Secret-123" and they've used "Secret123", then you've presumably got a better chance of guessing what my password is than if the LSHes weren't stored (if you can't get from me directly, you can try to get it from others who have the same LHS).

You could salt the LSH with a different per-user salt.

Re: Password Requirements: Myths and Madness

#150

Post by wizofaus »

gpderetta wrote: post #149
wizofaus wrote: post #118

Earlier quoted context omitted.

Surely even having an LSH stored is a potential compromise - e.g. if my password happens to have the same LSH as somebody else because I've used "Secret-123" and they've used "Secret123", then you've presumably got a better chance of guessing what my password is than if the LSHes weren't stored (if you can't get from me directly, you can try to get it from others who have the same LHS).

You could salt the LSH with a different per-user salt.

True, if you were only concerned about similarity with the same user's passwords.
Post reply on HN