Hacker News Reader

Comment by hsdropout | Hacker News Reader

This has been in their guidance since at least 2017.

"Verifiers SHOULD NOT impose other composition rules (e.g., requiring mixtures of different character types or prohibiting consecutively repeated characters) for memorized secrets. Verifiers SHOULD NOT require memorized secrets to be changed arbitrarily (e.g., periodically). However, verifiers SHALL force a change if there is evidence of compromise of the authenticator"

https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.S...

Also worth pointing out that NIST doesn't set policy, so unfortunately this doesn't directly "forbid" anything, though many other policies reference 800-63.

View on HN

Before the change : https://pages.nist.gov/800-63-3/sp800-63b.html

"Verifiers SHOULD NOT impose other composition rules (e.g., requiring mixtures of different character types or prohibiting consecutively repeated characters) for memorized secrets. "

After the change: https://pages.nist.gov/800-63-4/sp800-63b.html

"Verifiers and CSPs SHALL NOT impose other composition rules (e.g., requiring mixtures of different character types) for passwords."

So advice to requirement for this part, which is great!

> SHOULD NOT require memorized secrets to be changed arbitrarily (e.g., periodically)

Are there employers that follow this advice? Mine won't (and won't say why).

The only employer I've had which had a dumb rotation rule was of course a huge American Credit Reference Agency which due to ordinary incompetence lost a lot of people's personal information.

These days I work in tertiary education, so there's a complete spectrum from people who probably have memorised a unique sixteen alphanumerics password twenty years ago to folks who needed a service desk worker to help them walk through resetting after having forgotten their password was the name of one of Henry VIII's wives. And there's likewise a spectrum between "I hand-built this optical splitter and splice so that I could steal the exam answers without any trace on the network" and "I wrote the formulae on my thigh in permanent marker and then wore a skirt with a big slit down one side" in terms of the technical sophistication of attacks.

Edited to add: When I did work for the CRA with the rotation rule I would write down each of the passwords in columns in the back of my log book since otherwise I might forget one and that was a huge pain to get reset, it's just not realistic to memorize "random" values you'll have to replace frequently. And of course they had two "Single" Sign On systems because of warring management, so that's two passwords to rotate.

It’s because the CIO or whomever is running the show is a relic from the 1990s. I can tell a lot about a company by their password policies. There also seems to a direct correlation to silly password and “security” policies and the usage of Microsoft products such as Teams and Outlook.

> It’s because the CIO or whomever is running the show is a relic from the 1990s.

More often, it's because the "cybersecurity insurance" is a shitshow. When you as a CIO deviate from their requirements and get 0wned, you're getting stuck with the bill.

I've found it commonplace these days at least in europe that organisations use SSO via an identity provider that requires MFA for everything they can - even clients who are banks and utilities that usually move at a glacial pace.

The last time I worked anywhere with periodic password change was 8 years ago and they were phasing it out. The same place would reset your password to Monday123 if you got locked out (whether you needed a password reset or not) and forget to set the "force change" flag.

I wonder what will happen if I post a provocative „Why is our IT department violating NIST password recommendations?“ in public slack.

In my experience, you get labelled as not being a team player.

Or a busybody (speaking from personal experience).

About 18 months after me raising this issue and referencing both NCSC and NIST, the rules at the org I'm contracting with were changed.

I have no idea whether my suggestion made any difference.

We use NIST as a baseline. Some organisations actually try to do this properly :)

Yes. My very large employer hasn't required me to change my password in over two years. But at the same time, 2FA requirements have changed to more secure forms (going from having to select one of 3 numbers on a prompt to having to type in the number, for example), and some resources can only be accessed using a hardware key or even a special laptop.

I've encountered situations where the requirement to rotate passwords was obligated by contractual agreements. For instance, this is still the published guidance documentation on the HHS website for HIPAA compliance (https://www.hhs.gov/sites/default/files/ocr/privacy/hipaa/ad...):

  > Covered entities must train all users and establish
  > guidelines for creating passwords and changing them
  > during periodic change cycles.

If you have a contract that deals in HIPAA related information, you might be contractually obligated by the entity subject to HIPAA to have password rotations so that they can check the right boxes for compliance. Even though HIPAA isn't supposed to dictate specifics, I sure would't want to be the person that has to explain why they didn't have password rotations in a HIPAA breach report, not matter what NIST said people "should" do. Because between a NIST "should" and the document labeled "HIPAA Security Series" and "Security Standards", in the middle of a shit storm, I wouldn't be counting on folks appreciating the nuances between the two.

From the employer POV, employees cannot be trusted to discover their passwords are compromised, so updating them limits the duration the leaked password works.

Did NIST not take this into account?

Frequent changes mean more people write them down.

Frequent changes are a good way to move the blame on employees

It seems it’s been upgraded to SHALL NOT this year.

Aha good point, my bad.

NCSC has advised against arbitrary forced password changes since 2015 https://www.ncsc.gov.uk/blog-post/problems-forcing-regular-p... - one day we might see this practice gone

> Also worth pointing out that NIST doesn't set policy…

Which has a side effect of NIST not even following its own guidance!

For this particular issue, it took a while but the NIST password policy does follow 800-63 now. They changed it a while back.

Reply on news.ycombinator.com