Password Requirements: Myths and Madness • Hacker News Board

Re: Password Requirements: Myths and Madness

#231

Post by [deleted] » Fri, Dec 23, 2022, 3:14 PM UTC

alanfranz wrote: post #228

e12e wrote: post #211

I recall a talk at passwordcon by Per Thorsheim where he pointed out that not only does the password: "Password2022" meet most "strict" criteria (three different character classes, longer than eight characters) - and -it's amenable to yearly demands for changing (increase the year) - but in large organizations you're actually very likely to find a user or two with this password (as seen in audits that ran simple brut…

One good complexity check would be “contains a single dictionary word as the main content.” I don’t know if library does it, though.

[deleted]

Re: Password Requirements: Myths and Madness

#232

Post by yourapostasy » Fri, Dec 23, 2022, 3:25 PM UTC

Jenk wrote: post #203

yourapostasy wrote: post #194

Earlier quoted context omitted.

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

The only PCI DSS requirement I couldn’t quickly align to NIST and others has been the 90 day expiration. My go-to has been to convince the insurance underwriters first of the primacy of SANS, NIST, Microsoft and so on. Then put them in a locked cage match with the PCI DSS auditors and accept the result when they walk out. PCI DSS auditors can’t accept liability shifting onto them, and cybersecurity insurance underwriters are getting more savvy on current standards and can often twist auditor arms enough to carve out exceptions and still obtain the audit certification.

It’s still messy at this time, but if it is important enough to you, then sometimes it can be obtained. Most of my clients aren’t that doctrinaire over the expiration part though and are still comfortable making everyone change every 90 days, and with some enterprises they don’t care because they have FIDO2/U2F or similar authN infrastructures and corresponding authZ improvements on their roadmaps within the next 3-5 years anyways that do away with most passwords in their environments.

Re: Password Requirements: Myths and Madness

#233

Post by [deleted] » Fri, Dec 23, 2022, 3:28 PM UTC

danrocks wrote: post #23

chordalkeyboard wrote: post #17

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

[deleted]

Re: Password Requirements: Myths and Madness

#234

Post by Thiez » Fri, Dec 23, 2022, 3:29 PM UTC

AussieWog93 wrote: post #108

II2II wrote: post #91

Earlier quoted context omitted.

Expiring passwords are the bane of my existence when the period is short. I can live with changing a password once a year, but every three months is only encouraging me to pick weak passwords. Why can I accept it? I constantly see colleagues sharing passwords and constantly have to say "please don't" when they try to share their password with me. While forcing people to change their passwords doesn't eliminate the un…

My old man's work used to make them change their passwords once a month. For the next 10 years, his password was a particular insulting phrase directed at the IT guys, followed by a number that would increment each time he had to change it. Got into the hundreds before he left the company.

I had a coworker that would type in something random as his new password, then immediately fail to login three times in a row so his account would get locked. To fix this the sysadmin would reset the password, and allow you to choose a new password... and on the no-repeated-passwords policy did not apply to the magical reset dialog. So he would then reset it to his old password.

Re: Password Requirements: Myths and Madness

#235

Post by alanfranz » Fri, Dec 23, 2022, 3:31 PM UTC

throwawaaarrgh wrote: post #220

alanfranz wrote: post #208

Earlier quoted context omitted.

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

Password manager password generators have a simple UI you can click to select the password format required by the form. Or just click 'generate' again and try each until one works.

So, you need to bother, either to reverse-engineer the site requirements, or to try until it works.

For no good reason, as explained in the article.

Re: Password Requirements: Myths and Madness

#236

Post by csydas » Fri, Dec 23, 2022, 3:40 PM UTC

AstralStorm wrote: post #128

csydas wrote: post #110

Earlier quoted context omitted.

ah, that's reasonable and logical I guess to just do common "simple" transformations and check the hash. Thanks!

It's not that easy, normally having function have a big avalanche factor - even one bit changes the whole hash. There are some malleable having algorithms but they're necessarily less secure. If you're sending multiple hashes to check nobody is stopping the user from sending garbage, except their lack of JS/browser skill. If you're sending the plaintext password, what are you doing using a hash? When your backend is…

No, I think you misunderstood the post I responded to a bit.

In the case where the current password is captured on the password change, you have two plaintext values that aren't stored yet and you can just do some text analysis and understand how close they are.

With past passwords, you just take the current input and transform it with common transformations (adding numbers, incrementing/decrementing numbers, etc), hash it, and see if it matches a previous password hash. If so, then you know that they're using a very similar password pattern repeatedly.

Re: Password Requirements: Myths and Madness

#237

Post by cirrus3 » Fri, Dec 23, 2022, 3:57 PM UTC

ar_turnbull wrote: post #45

joezydeco wrote: post #11

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

would be a nicer UX if instead of "sorry" it was "great, your password hasn't changed as this was your old password. ps. you're now logged in, go do whatever you were hoping to do you rascal!"

Depends on the reason the user could not login. If they really just forgot, then maybe that would nice UX... maybe. It could also be concerning to an unaware user that that somehow the site knew my old password (even though _we_ know they are just comparing hashes). If the login was disabled due to the site knowing the hash of the old password appeared in a rainbow table somewhere, it would be a terrible idea to just let them use it again.

Re: Password Requirements: Myths and Madness

#238

Post by taeric » Fri, Dec 23, 2022, 4:05 PM UTC

AnIdiotOnTheNet wrote: post #219

taeric wrote: post #214

Earlier quoted context omitted.

This is, essentially, harder to remember passwords. Probably more secure, provided you don't make a mistake. But also easier to mistake and then lock yourself out. Auditing is also harder, now

No it isn't, because unlike passwords you can reuse a key pair indefinitely without suffering any greater risk. If we only ever had to remember a handful of passwords you would be right about them being easier, but we have hundreds of them which necessitates a password manager anyway which has all the same manageability problems of the asymmetric key pair without any of the benefits. > Auditing is also harder, now Ca…

You still have to remember what it is that you signed. Unless you are saying it is a challenge/response thing. In which case you have to know what public key they have.

And if it is challenge/response, you need to have different public keys, or a compromised private key is complete game over, just like a shared password.

Thinking on it more, I'm not sure why I think auditing is harder. Is hard regardless, but I don't think this makes it tougher. If you are reusing public keys on N sites, it is now N places to check for use per key. Though, you always had N places to audit. They could be independent without reuse, but still not easy.

Re: Password Requirements: Myths and Madness

#239

Post by the_af » Fri, Dec 23, 2022, 5:11 PM UTC

lucb1e wrote: post #50

the_af wrote: post #30

Earlier quoted context omitted.

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

So what's the proposal, switching to requiring a different length when a unicode character is present? How do you know from what set of possible values (like thousands of possible unicode chars versus a-z) the user chose each character? While 68 bits entropy are secure in a case of good hashing, I think the statement is misleading. Anyone who uses a random generator will just use 16+ random alphanumerics (optionally…

I think the argument, aimed at the people making the website/app (but not the login, which should be a third party), is that they should ditch ad-hoc and ill-advised password constraints and instead go with a well vetted third party lib that just measures password "strength".

A variant of "don't roll your own crypto (unless you work in the crypto space)".

Re: Password Requirements: Myths and Madness

#240

Post by taeric » Fri, Dec 23, 2022, 5:14 PM UTC

sdfhbdf wrote: post #222

taeric wrote: post #196

Earlier quoted context omitted.

Passkeys aren't immune to phishing. And they are susceptible to being lost. I say that as someone with two. Worse, they aren't accepted everywhere. And often places only let you have one registered. :( So, yes, I agree that they are a solution. I don't know that I feel much safer using one, though. And, at large, I can see how they are not much different to passwords. Just ones that you can't speak others easily.

Are you sure you’re referring to passkeys like passkeys.dev? The new Web standard? It builds upon WebAuthn and physical keys but is slightly different and on track to be supported by major platforms. Sounds like you’re referring to something like YubiKey, it’s hard to lose device associated passkeys. How would you phish it? The challenge response mechanism contains the requesting origin so it’s berry difficult to phi…

You are correct I meant yubikeys. I'll have to look a bit more at this new thing.

I confess right now it isn't impressing me. Is sounding too magical in a "it just works" way. With no real explanation of how.

It hurts that it sounds tied to a device. I stopped using some authenticator apps after I lost access to a ton of stuff when my phone broke.

As for phishing, this seems like a mitm would still work better than you'd expect. Folks get really good at ignoring warnings and such. Especially under duress.