Password Requirements: Myths and Madness • Hacker News Board

Re: Password Requirements: Myths and Madness

#201

Post by alanfranz » Fri, Dec 23, 2022, 1:29 PM UTC

zinekeller wrote: post #63

lolinder wrote: post #49

Earlier quoted context omitted.

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…

> but it's much more likely that someone just picked four that they like Or as I would call it, the fallacy of uniformity. The author assumes that hackers would only try a dictionary attack using lower case letters, but this is no longer true since mid-2010s. Some dictionaries geared for international services also have non-Latin characters since not all countries restrict passwords to alphanumerics.

If it’s four random Unicode code points, it’s not a dictionary word.

Re: Password Requirements: Myths and Madness

#202

Post by gtirloni » Fri, Dec 23, 2022, 1:29 PM UTC

>You waste a lot of time at generating a "strong password" that complies with a website's policy

I let my password manager do it and don't bother with it any time soon.

Re: Password Requirements: Myths and Madness

#203

Post by Jenk » Fri, Dec 23, 2022, 1:32 PM UTC

yourapostasy wrote: post #194

mijoharas wrote: post #87

Earlier quoted context omitted.

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.

> 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"... Tip for those in settings with compliance reviews and cybersecurity insurance: get your PCI DSS, SOX, and other auditors, and cybersecurity insurance underwriter on board with these standards as well, with written statements. Then if Big Customer Co. pushes back…

It's actually PCI DSS that has propagated some of these bad practices.

Re: Password Requirements: Myths and Madness

#204

Post by AnIdiotOnTheNet » Fri, Dec 23, 2022, 1:35 PM UTC

taeric wrote: post #126

AnIdiotOnTheNet wrote: post #112

Earlier quoted context omitted.

Honestly I'm surprised we're still using user names and passwords for authentication and identification in 2022. We have come up with many better ways to do this, and just completely failed to adopt any of them as the new normal. The closest we get is when we can use Google or Facebook to log into Joe Blow's Bullshit site instead of a bespoke account.

I'm afraid to ask what you think are the better ways? My assertion is that most risk of online fraud is a social, not a technical problem. As such, it will require law to make safe.

For example, asymmetric key pairs. Give sites a public key and auth by signing something with your private key. You can use the same key on as many sites as you want, but you can also use different keys for different sites. No need for a third party even.

Re: Password Requirements: Myths and Madness

#205

Post by bombcar » Fri, Dec 23, 2022, 1:46 PM UTC

vanviegen wrote: post #122

bombcar wrote: post #66

Earlier quoted context omitted.

B2B is worse because EVERYONE shares business accounts with other people at the business. And so the usernames passwords and even two factor setups are passed around like coffee. “Oh use bobs login for that, the standard password but add a ! for reasons”

That's what you get when vendors charge per seat.

I have a sneaking suspicion that Salesforce is pushing 2FA so hard to sell more seats. And $6k/yr/pop it’s gotta be tempting to share a password …

Re: Password Requirements: Myths and Madness

#206

Post by archi42 » Fri, Dec 23, 2022, 1:48 PM UTC

MaxGabriel wrote: post #46

_dan wrote: post #32

In the b2b world it's basically impossible to improve password policies. Most of the onerous examples only exist because some other entity (a customer, insurance company, parent company, etc) has demanded them. The problem is that the demand isn't being made by security professionals, it's being made by risk management people who are only interested in a simple way to mitigate risk - it's simply much easier for them…

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

The topic of "what should we do about our password policies" sometimes comes up with our customers as well. Pointing to NIST and if pressed giving my opinions on good passwords and the use of 2FA (which is largely paraphrasing NIST recommendations anyway) made every customer happy so far :)

Re: Password Requirements: Myths and Madness

#207

Post by cm2187 » Fri, Dec 23, 2022, 1:50 PM UTC

JimDabell wrote: post #99

> There's no technical reason for restricting any character from appearing in any password. The usual approach for handling a password is: > - encode with a specific, well-defined encoding (e.g. utf-8) Heads up – this is not enough for reliable operation. The same character from an end-user’s perspective can be encoded in multiple ways in UTF-8. So they might register with one platform and then a while later log in w…

Likewise the hex of a 128bit key is unbreakable but will fail almost every password policy becuse of repeated characters and lack of upper case/special characters.

Though for accentuated characters, I can think of some scenarios where it is not a good idea. Say your users may have to travel / use some terminals. If the keyboard doesn't have those characters, you locked them out of the system. That's why I think non ascii characters aren't a good idea. Also you make yourself more exposed to developers doing something silly like mixing string encoding between different interfaces.

Re: Password Requirements: Myths and Madness

#208

Post by alanfranz » Fri, Dec 23, 2022, 1:57 PM UTC

gtirloni wrote: post #202

>You waste a lot of time at generating a "strong password" that complies with a website's policy I let my password manager do it and don't bother with it any time soon.

But your generated password contains "-", and that's not accepted by the website. How can you not bother?

Re: Password Requirements: Myths and Madness

#209

Post by alanfranz » Fri, Dec 23, 2022, 2:14 PM UTC

makach wrote: post #161

Your passwords are safe as long as you have done your part, i.e. followed best practice on how to set up your passphrase for accessing your information. LastPass implemented a system that is durable, as long as your HW is not compromised or you are somehow duped into giving away your password you should expect your passwords to be safe. If you are worried, change your passphrase in accordance with best practice and y…

Did you just comment on the wrong article?

Re: Password Requirements: Myths and Madness

#210

Post by alanfranz » Fri, Dec 23, 2022, 2:17 PM UTC

regularjack wrote: post #10

Off-topic but not sure having a patronizing cookie banner is the best strategy.

It’s a very old banner, I didn’t mean for it to be patronizing, just to mock the absurd cookie law which had just passed.

I’m trying to go cookieless, actually, I hope to finish someday, Google Analytics was removed already. I’ll need to ask for explicit authorization for disqus commenting only.