Live data from Hacker News

Password Requirements: Myths and Madness

franzoni.eu

191–200 of 257 posts

Re: Password Requirements: Myths and Madness

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

You will get this reply: "NIST is an American institute, and we are a Japanese company, we have our own standards that differ, and must follow them".

Re: Password Requirements: Myths and Madness

#192
My company recently switched to something probably inspired by the NIST standard. We are supposed to have a unique password, that never expires. The "problem" is that we are now required to use 2-factor basically every time we sign in instead, which is annoying, and the login also times out way too fast of course. Previously I could be logged in for days? Now its hours and I need to then use my phone to log in. (I only work remotely, but being a firm of contractors its what most of us do.)

Re: Password Requirements: Myths and Madness

#193
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'm reasonably certain that I'm not your father but I used to do that too - although I don't think I made it into the hundreds.

Re: Password Requirements: Myths and Madness

#194

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.

> 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 after you say, "we're not prepared to reduce our security", ask them in a friendly way to hold an N-way meeting between their auditors and insurance underwriter, and your auditors and insurance underwriter.

This gets them to switch off their demand. Every. Time. If they don't back off on their own, their auditors and/or insurance underwriter makes them back off. I've yet to have such a Big Customer Co. push it to the point of asking more than one of their own auditors, though. Usually it is someone not in auditing and insurance underwriting blithely following outdated policies written in the Stone Age that still need updating, and most are grateful for the updated clarification.

You have to get out ahead of the business risk though for this to work: you need to properly socialize the delay this puts on the deal "while auditors and insurers sort out the risk". This is where soft skills shine.

This approach will also take care of the response user patrakov gave ("NIST is an American institute, and we are a Japanese company, we have our own standards that differ, and must follow them"), once it gets to the insurance underwriters talking it over on how to divvy up the risk and amend their policies if necessary.

Re: Password Requirements: Myths and Madness

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

I work for an insuretech startup and have been through a number of compliance gauntlets with large enterprise insurance companies. Appealing to NIST recommendations for why we don't auto-expire passwords every x days and don't require anything more complicated than at least 10 characters has worked on every occasion.

Re: Password Requirements: Myths and Madness

#196
post #126

Earlier quoted context omitted.

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.

Passkeys, which are getting closer and closer to prime time. If you think about it, key-based auth is already highly recommended and utilized in many scenarios (like SSH, signing data, certificates, token authentication for use between servers, etc.)… this just makes that accessible to users. The vast majority of people don’t even use a password manager, and use variations of the same password everywhere. That’s real…

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.

Re: Password Requirements: Myths and Madness

#197

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

That’s correct. It’s quite a detail in this case, though; this high level description tries to explain why you should never forbid some “special” chars.

Please note that it’s not the same char; it’s actually a different set of code points which happen to have the same representation.

I’ll update the article nevertheless.

Re: Password Requirements: Myths and Madness

#198
post #127

Earlier quoted context omitted.

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

Backups! Copy of key at friends house.

If it is copiable, how would you know if it had been compromised?

My understanding is that backup keys should not be identical for that reason. Let's you revoke and audit use.

As such, having a backup has to be accessible so that you can register it places. There are tricks, but they only work in certain scenarios. Mostly not in the fido use cases.

Re: Password Requirements: Myths and Madness

#199

Earlier quoted context omitted.

Backups! Copy of key at friends house.

So that the friend, or someone who steals from the friend can impersonate me? Proving your identity when you lost your proof of identity is still an unsolved problem if you ask me. At least in general, it seems that there is no one solution that works for everyone.

Put a PIN on it...

You can remove the PIN later. The hardware key can be set up to wipe the device after, say, 10 incorrect guesses.

Re: Password Requirements: Myths and Madness

#200

> The usual approach for handling a password is: take the password as a string, as the user typed it. Ah. That usual approach, where any rogue employee or anyone really snooping on either side of the connection before/after the TLS gets to see the plaintext password. Makes me wonder: is salted challenge response authentication (RFC5802 and 7804) getting any traction? Couchbase is (was?) using that. Is there a list of…

I didn’t know that rfc, but afaik the usual way is what I’ve written.

Will take a look at that,btw. Looks interesting.

Post reply on HN