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

121–130 of 257 posts

Re: Password Requirements: Myths and Madness

#121

Post by AstralStorm »

II2II wrote: post #91
Bilal_io wrote: post #71

Earlier quoted context omitted.

Expiring passwords are the bane of my existence. My current job does that. It was originally a requirement by Microsoft and they've been recommending against it, but it catches up slowly.

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…

Changing the password opens it to compromise when it's being changed. Capture of that account is possible and easy at that point.

It also interferes with password managers and secure keys. Opens a phishing vector. Generally I could enumerate how bad it is and run out of ink here. (And it's a screen.)

Re: Password Requirements: Myths and Madness

#122

Post by vanviegen »

bombcar wrote: post #66
_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…

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.

Re: Password Requirements: Myths and Madness

#123

Post by js2 »

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

My company requires us to change our password every 90 days due to such externally imposed demands so mine ends in two digits which have been counting up for almost ten years now.

Re: Password Requirements: Myths and Madness

#124

Post by AstralStorm »

wkat4242 wrote: post #98
ddejohn wrote: post #96

Earlier quoted context omitted.

Typing a passphrase is so much easier. You already have muscle memory for typing English (or whatever your first language) words. I can type probably type a 60 character passphrase consisting of real words at least as quickly as than I can type a 15 character password with special characters, if not faster.

For you maybe, not for me. I'm pretty good with arbitary strings. And I'd only use specials that don't require shift :) It's really much faster and I have RSI so I don't want to type too much. Luckily my work still allows 10-char with specials or passphrases of 16 and longer without. And don't forget passphrases only benefit in very specific situations such as hash brute forcing. Online attacks already block after a…

Use a secure element with a password manager already. Specifically, certain password managers can handle yubikey as storage.

Re: Password Requirements: Myths and Madness

#125

Post by TedDoesntTalk »

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’re assuming an attacker can access this database somehow? And that the LSH of “somebody else” is reversible? I’ve don’t understand the vulnerability you’re describing.

Re: Password Requirements: Myths and Madness

#126

Post by taeric »

AnIdiotOnTheNet wrote: post #112
bruce511 wrote: post #94

The article is correct, most password policies are dumb. But it's arguing about one tree while standing in a forest. The real problem with passwords is not individual policies, but rather their shere volume. In my password manager I noticed I have got literally hundreds of the things. Clearly reusing a password on multiple systems is bad. Clearly memorizing more than a handful is impossible. Since I therefore am usin…

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.

Re: Password Requirements: Myths and Madness

#127

Post by taeric »

nigerianbrince wrote: post #106
bruce511 wrote: post #94

The article is correct, most password policies are dumb. But it's arguing about one tree while standing in a forest. The real problem with passwords is not individual policies, but rather their shere volume. In my password manager I noticed I have got literally hundreds of the things. Clearly reusing a password on multiple systems is bad. Clearly memorizing more than a handful is impossible. Since I therefore am usin…

Our computers should have a specific port for a physical key which we would carry around in our keychain.

And what do you do when your key is broken or lost? Because that will happen.

Re: Password Requirements: Myths and Madness

#128

Post by AstralStorm »

csydas wrote: post #110
koolba wrote: post #78

Earlier quoted context omitted.

> Past password similarity checking (I'm actually not even sure how they do this unless they somehow have access to the plaintext version of user passwords; if there's a benign/secure way of doing this I'd be very curious) Most systems that allow you to change your password require the current password as a verification. This means the software performing the validation of the new password also has access to your old…

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 compromised, attacker will just grab all the password when they're getting changed.

Re: Password Requirements: Myths and Madness

#129

Post by AstralStorm »

jlund-molfese wrote: post #80
nulbyte wrote: post #69

Earlier quoted context omitted.

> - Past password similarity checking (I'm actually not even sure how they do this unless they somehow have access to the plaintext version of user passwords; if there's a benign/secure way of doing this I'd be very curious) Same way you verify the current password: hash it and compare to what you have on file. If you use salted hashes and the salt changes, you'll have to keep enough of those around, too.

How would that work for password similarity ? If they’re using some special hash algorithm that retains most of the information of the original password and allows them to determine that “password1” and “password2” are similar and “blahblah7” is not, their approach is hopelessly broken too.

Technically you could tokenize and dictionary plus edit distance check the password in the client if you have the plaintext, or use malleable hashing. Check entropy while at it. Of course that will not stop a determined policy ignorant.

Requiring a plaintext password storage somewhere is an instant regulatory fail in ISO 27002 and PCI DSS standard. You can technically store the passwords encrypted, but attacker is liable to steal your salt/key, and protecting the passwords in transit strictly requires strong PKI. We know users cannot determine that anyway and get phished/MITMed.

Plus it's kind of mean. If your users are determined to ignore your policy, maybe it's a bad policy or you need to tell them to stop doing that.

Checking for x latest passwords requires just storing their hashes.

Re: Password Requirements: Myths and Madness

#130

Post by lamontcg »

Where this came from is stuff like the DES crypt implementation where passwords were truncated at 8 characters and then 7 bits were extracted to form a 56 bit DES key. You simply couldn't have long passwords back then. The first widespread crypt implementation that could handle long passwords was probably PHKs MD5 based scheme in 1995 -- contemporaneously around the release of Netscape Navigator.

If you only had 8 characters then you needed to include multiple different character types and needed to not use dictionary words. So for the early internet those became the standard recommendation until long-password-supporting crypt()s became standard in operating systems.

Having gone through a decade-ish of those password standards in the 90s by the time all the operating systems had updated their crypt() standards a lot of people didn't really notice until the xkcd comic in 2010. And now you've just got to fight 30-ish years of inertia of those being considered the standard.

Post reply on HN