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]”.
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.
