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

181–190 of 257 posts

Re: Password Requirements: Myths and Madness

#181

Post by AshamedCaptain »

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 was doing the same at one point, albeit it only lasted 5 years before I changed employers. Didnt even had to rotate the numbers, I could always come up with new and colorful insults for the nameless IT group. Which ironically I remember perfectly.

Re: Password Requirements: Myths and Madness

#182

Post by eastbound »

ethanzh wrote: post #166
eastbound wrote: post #92

Earlier quoted context omitted.

I’m a small company and the problem with SAML is that it requires the “enterprise” plan for each app. Slack goes from 0 to $11.75/month/user, Miro goes from $8 to $16. Then you have to pay for Okta (Isn’t it $15/u/m?) For a 5-person business it’s $1185 difference + $900 for Okta, and that doesn’t make me SOC2 compliant (There is a bunch of other requirements, secure access to physical offices, logs, etc.).

sso.tax lists tons of examples of the price increases you’ve mentioned

I love that! Needs to be more known, it’s like SSL certificates when LetsEncrypt didn’t exist.

Edit: It has been posted 7 times in the last year.

Re: Password Requirements: Myths and Madness

#184

Post by _dain_ »

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.

Across the pond, there is also the NCSC password guidance. It's better than linking to some obscure paragraph in a standards document; it's written in plain English, aimed at the layman, and explains exactly why the old doctrines are bad:

https://www.ncsc.gov.uk/collection/passwords/updating-your-a...

Re: Password Requirements: Myths and Madness

#185

Post by _dain_ »

mijoharas wrote: post #89
dalyons wrote: post #76

Earlier quoted context omitted.

I think you missed the word “similarity”. You can’t check similarity with hashes, only exact matches

Oh god! I made the same mistake. I thought you just meant password reuse. Past password similarity? That's literally impossible without plaintext passwords isn't it. That is insane.

The hashing has to happen serverside, which means the server will temporarily have the plaintext in memory. While there, you can mutate the string by adding/removing/chanigng characters, to get a bunch of strings that are similar. Then you compare all of those to the old hashes you have stored. It will catch people doing common stuff like incrementing a number at the end on every reset.

Re: Password Requirements: Myths and Madness

#186

Post by TacticalCoder »

> 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 websites that went past what's basically the nineties' "plaintext password over SSL"?

Re: Password Requirements: Myths and Madness

#187

Post by _dain_ »

dspillett wrote: post #170

> You cannot enter a password with more than X chars I've seen this from banks , for access to my money & credit... Both FirstDirect and HSBC used to have a 9 character password for their "digital secure key"s (basically their apps on my phone, in the direct use use-case). 9. Just 9. Though at least alpha-numeric & case-sensitive, so some room for reasonable entropy. Worse: for some reason HSBC recently changed their…

>Worse: for some reason HSBC recently changed theirs to 6 numeric characters. 6. Numeric only. And while forcing me to change, they repeatedly assured me that this was just as secure as before… Luckily for me all I have with them currently is a mortgage that I'll be paying off in (checks calendar) a week and a half, at which point the whole lot gets closed and they can make it a two digit PIN for all it'll affect my financial security!

I'll one-up you: Nationwide requires six numeric characters, which you have to enter via one 0-9 dropdown menu per digit, and you only have to enter three per login.

i.e. if your "passcode" is 987654, then it will randomly choose only three of those for you to enter, like

    _?_??_
where you'd only have to put in 8, 6, and 5. So it's clearly stored in plaintext. And they have 2FA, but as you might expect, it's SMS only.

And their online banking site is garbage, some links just always timeout and log me out.

Is there a single UK bank that has the following two features: 1) lets me pick a sane password and has non-SMS 2FA, 2) has an online banking interface that works on desktop browsers.

The second one is important to me because I never want to do banking on my phone. Last time I checked, the "challenger banks" like Monzo only have phone options.

Re: Password Requirements: Myths and Madness

#188

Post by nicoburns »

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”

We setup bitwarden at work, and it was absolutely fantastic for these sorts o shared accounts. You could have all the password be telling random strings, and control who had access to them with a convenient UI. Password rotation became a lot easier too, because all you had to do was update the password in the password manager and everyone would have the new one.

Re: Password Requirements: Myths and Madness

#189

Post by nicoburns »

lttg wrote: post #117
_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…

I was in charge of password policy for a healthcare app. We tried to use phrases, often cited as more secure than character/length requirements. The doctors hated it. They didn't understand what a phrase was, it was too different from every other system they interacted with, and it was extra cog load in their already busy days.

Why not just have a length requirement and recommend a phrase? “Passphrase” isn’t that common a word, so it merits an explanation. But “your password has to be long, but you don’t need to use special characters, and can use regular english word if you want” is surely easy enough to understand.

Re: Password Requirements: Myths and Madness

#190

Post by mijoharas »

fragmede wrote: post #148
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.

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

Sure! I used NIST[0] (which has already been posted here), along with Microsoft[1] and the UK National Cyber Security Centre[2] (we're in the UK as well as the US).

For context, I remember the contract first came back, and we redlined it saying we're not gonna do password expiration and explained why. It then came back with another draft and they said "no, this is our policy, you definitely need to do password expiration" so I threw these references together and expanded my explanation. It was a bunch of business/lawyer types, so I threw microsoft in there as I assume they're better known to non-technical people and the other two references are obviously more salient to technical people.

As a side-note I think this was _after_ they had their very well publicized security breach, and I would have hoped that they had taken a look at their security and updated their policies but I guess that wasn't the case. I don't know whether they ended up removing it from their contracts going forward or just made an exception for our one. The cynical part of me says the latter (it's a big firm, and we're not a particularly big one) but I can hope.

I also recently read an audit for another third party we were evaluating to work with. I raised it as a non-blocking concern saying they're not following modern password standards, and I think if everyone does that these companies will start to update their policies but for now it's fairly common at least in my industry.

[EDIT] I went looking for what I actually said to them, and it was "as per UK/US government and Microsoft password guidelines, we will not agree to this, and would prefer if you didn't do it as well.". So I guess I was a bit exasperated with them at the time :)

[0] https://pages.nist.gov/800-63-3/sp800-63b.html#memsecretver

[1] https://learn.microsoft.com/en-gb/archive/blogs/secguide/sec...

[2] https://www.ncsc.gov.uk/collection/passwords/updating-your-a...

Post reply on HN