Passwords, NIST and business practice

A shared pain of all people working in the pharmaceutical industry (or in fact any highly regulated industry) is the well known 

"Your password will expire tomorrow. To change it......" request Windows raises every few month. 

Based on a National Institute of Standards and Technology (NIST)  guideline written when USB was not even invented, when "Internet" was something only few people have had contact with and Floppy disks were used to install Windows 95, all major player joined this utterly  counterproductive compliance game.

And to be honest: Back then it wasn't even a bad idea. To crack the password of an old Windows 95/98 system isn't exactly rocket science. So if an attacker could get his fingers on the file in which the password hashed are stored it took him only minutes to find an actual working password to log into an account (Offline attack). 

With Windows XP that time increased to several months.

Real online attacks on Windows user accounts by trying different passwords aren't something seen widely. Accounts will be blocked after 3, 5 or 10 wrong password entries and increasing delays are added to each try. 

But the idea that somebody who stole a disk from a computer after some weeks suddenly knows the user credentials (or at least valid passwords) of all users which ever logged into the computer from which the disk originated is scary. 

However:

Times changed, not even Windows uses poorly design password hashing anymore.

Nowadays brute forcing a password hash for a windows system is, even on the most powerful systems available, a question of years instead of minutes (given the password is "secure enough"....)

But the "Your password will expire"-mimimi remained.

And as the time went by people started to challenging the idea.  

Because let's be honest, how does it work for the majority of users?

You create a basic password and every 2 or 3 months the included number is increased by 1.

When I left my last employer after 20 years, I was at 83....

And that's the weak point of the whole "password change requirement" disaster.

It must have been around xxxx40xxx when Cormac Herley from Microsoft Research together with Paul van Oorschot from Carleton University published their paper  https://doi.org/10.1109/MSP.2011.150  on that topic in 2012.

Citing Y. Zhang, F. Monroses', and M.K. Reiters' 2010  “The Security of Modern Password Expiration: An Algorithmic Framework and Empirical Analysis” paper they state that an attacker who knew the old password could quickly guess the new  one 41 percent of the time in offline and 17 percent of the time in online attacks, while the paper itself states a way more damning "we confirm previous conjectures that the effectiveness of expiration in meeting its intended goal is weak." 

 

Over the years more and more studies on that topic popped up and while I tried hard to find one, I failed to identify a single one which concludes at least some positive effect on time base driven password exchanges.

 

At some point in time enough activation energy was available to make more people thinking about it.

The National Institute of Standards and Technology (NIST) in the U.S. revised its password guidelines in 2017, and one key change was discouraging mandatory password changes unless there’s evidence of a breach.

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

The current version of the guideline repeats that.

3.1.1.2 Password Verifiers - 6. Verifiers and CSPs SHALL NOT require users to change passwords periodically. However, verifiers SHALL force a change if there is evidence of compromise of the authenticator.

Other regulators have done similar, like the German Federal Office for Information Security.

According to their ORP.4 guideline section ORP.4.A23 "IT systems or applications SHOULD ONLY request a password change with a valid reason.Purely time-controlled changes SHOULD be avoided."

 

So here we are, 7 years after NIST updated its' guideline and still do password changes every few weeks instead of doing the only right thing and start using strong passwords.

But then the question is, what exactly is a strong password?

The idea that there has to be a combination of numbers, letters and special chars and everything is fine is at least misleading. Length matters here.

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