June 20, 2023

A Simpler Password Policy

Should you force employees to regularly change their passwords? NIST says no.

A Simpler Password Policy

Sleek v2.0 public release is here

Lorem ipsum dolor sit amet, consectetur adipiscing elit lobortis arcu enim urna adipiscing praesent velit viverra sit semper lorem eu cursus vel hendrerit elementum morbi curabitur etiam nibh justo, lorem aliquet donec sed sit mi at ante massa mattis.

  1. Neque sodales ut etiam sit amet nisl purus non tellus orci ac auctor
  2. Adipiscing elit ut aliquam purus sit amet viverra suspendisse potent i
  3. Mauris commodo quis imperdiet massa tincidunt nunc pulvinar
  4. Adipiscing elit ut aliquam purus sit amet viverra suspendisse potenti

What has changed in our latest release?

Lorem ipsum dolor sit amet, consectetur adipiscing elit ut aliquam, purus sit amet luctus venenatis, lectus magna fringilla urna, porttitor rhoncus dolor purus non enim praesent elementum facilisis leo, vel fringilla est ullamcorper eget nulla facilisi etiam dignissim diam quis enim lobortis scelerisque fermentum dui faucibus in ornare quam viverra orci sagittis eu volutpat odio facilisis mauris sit amet massa vitae tortor condimentum lacinia quis vel eros donec ac odio tempor orci dapibus ultrices in iaculis nunc sed augue lacus

All new features available for all public channel users

At risus viverra adipiscing at in tellus integer feugiat nisl pretium fusce id velit ut tortor sagittis orci a scelerisque purus semper eget at lectus urna duis convallis. porta nibh venenatis cras sed felis eget neque laoreet libero id faucibus nisl donec pretium vulputate sapien nec sagittis aliquam nunc lobortis mattis aliquam faucibus purus in.

  • Neque sodales ut etiam sit amet nisl purus non tellus orci ac auctor
  • Adipiscing elit ut aliquam purus sit amet viverra suspendisse potenti
  • Mauris commodo quis imperdiet massa tincidunt nunc pulvinar
  • Adipiscing elit ut aliquam purus sit amet viverra suspendisse potenti
Coding collaboration with over 200 users at once

Nisi quis eleifend quam adipiscing vitae aliquet bibendum enim facilisis gravida neque. Velit euismod in pellentesque massa placerat volutpat lacus laoreet non curabitur gravida odio aenean sed adipiscing diam donec adipiscing tristique risus. amet est placerat in egestas erat imperdiet sed euismod nisi.

“Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat. Duis aute irure dolor in reprehenderit in voluptate velit esse cillum”
Real-time code save every 0.1 seconds

Eget lorem dolor sed viverra ipsum nunc aliquet bibendum felis donec et odio pellentesque diam volutpat commodo sed egestas aliquam sem fringilla ut morbi tincidunt augue interdum velit euismod eu tincidunt tortor aliquam nulla facilisi aenean sed adipiscing diam donec adipiscing ut lectus arcu bibendum at varius vel pharetra nibh venenatis cras sed felis eget dolor cosnectur drolo.

They were marked for death but persist.

No, not some wily protagonist in an adventure film, but rather something a bit more mundane and usual: passwords.

Passwords remain as part of our daily lives, and any discussion about them provokes groans and sometimes grunts even though knowledge of passwords seems to be improving and password manager software proliferates. Yes, multi-factor authentication is increasingly available, but it’s not everywhere. And passwords remain the only way to prove who you are to many systems.

One might notice there are less and less notifications to change any particular system’s password on a regular basis. There’s a reason for this. The National Institute of Standards and Technology, known better as NIST, sets policy direction on such matters, and the bellwether implementers and the smarter of the herd often follow along. Note that those two groups are not mutually exclusive.

Earlier this year, NIST did make policy what many people in security already had determined: forcing users to change passwords at some regular time interval is a bad idea. The NIST publication 800–63b states:

Frequently forcing password changes is a bad idea since the likelihood of recall failure increases as users have more to remember. “With fewer memorized secrets, users can more easily recall the specific memorized secret needed for a particular [password]”.

Frequently forcing password changes is a bad idea

Okay, that’s great news from the perspective of those sick and tired of watching users forced to work around onerous password criteria and policies. Change a password monthly? Then users will keep the basic password if they can, and add the month. Users aren’t stupid. They know a good system hack when they see one.

But full stop now. There are times when passwords should be changed. It’s well-established that all passwords are ultimately breakable. Today’s unbreakable encryption is tomorrow’s plain text. If the adversary doesn’t have the computing power like some three-letter government agencies might, they do know that yesterday’s password encryption standards carry a shelf life.

All of history hitherto has been about unbreakable encryption being matched by encryption weaknesses. And, yes, the inverse is also true, and the struggle continues.

If a user is creating strong, memorable and unique passwords in the first place, as NIST says, let them remember them by not forcing password changes. But if users are not, then it makes more sense to do some password creation and storage training first. Once that task is showing fruition, then demanding a password change is unnecessary.

And for you, the user: you probably will know when you are more savvy with strong password creation. When you break a barrier in that area, plow ahead and change those weak passwords.

There are other times to change a password.

The most obvious is when a password may have been compromised. It might be reported that some adversary grabbed a copy of login information for some provider. Sure, it might be encrypted, but that data is now in the wild, and a basic line of defense has been breached. If the actual acquirer of that password information can’t break it, there’s a chance someone else out there could.

Therefore, if you are so kindly informed about a data breach from some entity to which logins and passwords are required for access, change that password as soon as possible. And if you can, change the login too.

Of course, if that data breach target is guilty of basic security protocols, consider changing the login, password and then consider replacing that provider. I hope you’re listening online banking services because even banks can be replaced.

But it’s not just a data breach from a financial institution or other online service that might provoke concern: software-based password managers are all-the-rage for the account inundated of the world. Password managers are really just a lot of lines of code written by very human developers, and compiled for the pleasure of the users. Those lines of code usually contain some mistakes, or incorrect assumptions, that can allow some adversary to access a password manager. Developers are humans too, encumbered by the work and personal stresses other humans face.

A password manager is a treasure trove of access. It won’t just get an adversary access to some frivolous music streaming service account. It can get them access to whatever sits in banking and retirement accounts. It can get them into the email account which all those other accounts use to reset their passwords.

It goes without saying, broken software provides the gateway to compromised passwords. Even simpler is today’s reality of too much exposure in applications and devices.

Almost twenty-five years ago, the few privileged online browsers could see that a simple web browser like Mosaic was the only thing connecting the clunky i386 chipped computer sitting under the desk to the wider internet. On occasion there might be a quick email POP-connection check, but there wasn’t much else. What those in the technical world call “network sockets” were minimal.

The walls, however, dissolved.

Few still use a mere document editors. Now there’s a full suite that is mostly remote and does little more than some presentation to the end user. What is entered by the keyboard is now already remote, on some obscured infrastructure most frequently referred to as “the cloud.” Thinking of it as “someone else’s computer” is probably more accurate.

That fact prompts another moment to change the passwords: if the password is unintentionally entered on a system where it’s not supposed to be. It might be that document editor or spreadsheet application. It might even be within an email, or on a chat server of some type.

Passwords should really only be entered where appropriate. If that’s not the case, it should be changed as soon as possible. The entered text may or maybe not be harvested intentionally, but to so many services today, harvesting text is part of the system, not an add-on.

Circling back around, being forced to change a password regularly is a hassle for users. It forces them to hack the process. The NIST is clear about it.

But knowing when passwords should be changed, with some event or mistake of some type, is a justifiable reason for a password change.

Better yet, once a better method of password creation is learned, implementing those lessons justify certain justify password changes. More on that to come.

George Rosamond is the CTO and Co-Founder of ClearOPS, Inc., a B2B SaaS privacy and security assessment and vendor management platform. George frequently writes on topics covering security, privacy and anonymity online.

About the author

I never met a repetitive, laborious task that I didn't want to automate.

Subscribe to our newsletter

Thanks for subscribing to our newsletter
Oops! Something went wrong while submitting the form.
Subscribe To Our Newsletter - Sleek X Webflow Template