After a long hiatus, it’s finally time for the next installment in Exploring OpenCASE.

If you’ve been waiting with bated breath, I apologise. Unfortunately since OpenCASE is just a passion project for now, finding time for it isn’t always easy. With the 2026.07 update looming however, I decided I better get back to it as a matter of Priority ;-) … Bad puns aside, if you missed the previous article on protecting your people, then make sure you take the time to check it out as well. Your people are the lifeblood of your business after all.

All right, let’s dive in…

Priority 3 - Protect your passwords.

Let’s address the obvious question first: Why have a separate Priority to “protect your passwords” when Priority 1 is already “protect your user accounts”? Given that Priority 1 is, practically speaking, really about multi-factor authentication, do passwords really even matter anymore? In short, yes they do, because authentication security is a multi-dimensional problem: it’s not enough to have really good locks, you have to protect the keys as well. MFA may be one of the most effective security mechanisms modern IT systems have (hence being Priority 1), but it’s not bulletproof. Cyber-criminals can use techniques like MFA fatigue attacks to defeat it under the right circumstances, but in most cases they have to have your password first for such an attack to be effective!

Priority 3 was deliberately designed to be functionally complementary to Priority 1. Remember that OpenCASE takes a layered approach to cybersecurity with its Implementation Levels; At Implementation Level 1, Priority 1 only requires MFA on primary user accounts (e.g. Microsoft 365 or Google Workspace). So what about all the other cloud apps and online services your organisation uses? Yes, ideally they should all have MFA too, but a typical small business has, conservatively, somewhere between 20 - 50 SaaS applications. Implementing, managing, and enforcing MFA across so many independent systems is no easy task, especially for a small business operating at the level of technical capability that is assumed by OpenCASE for Implementation Level 1. It’s not until we get to Implementation Level 3 that SSO or MFA for all cloud applications kicks in (where we assume a professional IT service provider is taking care of it). So, we have to take a more pragmatic approach at ILv.1, because at least some user accounts are only going to be protected by a password.

Unfortunately, due to 20 years of bad advice from security professionals, most people developed terrible habits around passwords. A combination of arcane complexity rules and mandatory password changes just taught people to do the all the things we were trying to get them not to do, i.e. use passwords that are easy for a computer to guess. Minimum 12 characters, and must include mixed-case letters, numbers, punctuation? No problem, password: “Collingwood2023!”. Need to change it? No problem, password “Collingwood2024!”. Can’t be the same as last 12 passwords? No problem, password “Collingwood2036!”. Rinse, repeat, wipe hands on pants… and of course, despite being repeatedly told not to, it’s the same password for every single application or site, because who the hell can be bothered remembering more than one password? Those clowns in IT can’t tell anyway…

Which brings us to the nuts and bolts of OpenCASE Priority 3: trying to make passwords suck less.

Implementation Level 1 - Store all passwords in centrally administered password manager.

In my experience, people don’t hate passwords so much as they hate having to remember them, and then having to type them in every 31 minutes because security goons insist on making session time outs for everything irritatingly short. Most bad password habits stem from this hatred: Using the same password for everything. Writing them on sticky notes attached to the monitor. Keeping them in a text file on the desktop called “PASSWORDS.TXT”. I’ve even met people who choose passwords that are deliberately bad but still technically meet the complexity requirements (like Collingwood2023!) out of spite.

All of this bad behaviour is entirely the fault of the cybersecurity industry. In our hubris, we thought we could get people to modify their behaviour just by making their jobs harder, rather than by giving them tools to make their jobs easier. It’s really no wonder that hacking techniques like brute force, password spraying, and credential stuffing became such a problem for cybersecurity professionals.

Password managers are the cybersecurity industry’s long overdue answer to all these (very legitimate) complaints: a secure, online repository for people to generate strong passwords, securely store them all in one easily accessible place, and automatically enter them when they need to log into a site. Honestly, its such an obvious idea that it’s embarrassing how long it took for the industry to make it happen. Part of that comes down to dogma - a lot of security goons couldn’t get past the idea that writing down passwords anywhere at all, let alone all in the one place, was BAD! In the end, pragmatism won out: an encrypted vault in the hands of a SaaS vendor turned out to be the “lesser evil” compared to “Collingwood2023!” everywhere, all the time. But I digress…

In a small business context, a password manager can give users a quasi-SSO experience which seems like magic after years of having to manually type in passwords all the time, but a stand-alone (i.e. personal or individually managed) password manager really only kicks the can down the road a bit. Inevitably, some user will forget their master password which is required to unlock the vault, and then it’s game over. All those very strong and impossible to remember passwords are suddenly unrecoverable and the very annoyed user has to spend a whole day manually filling out “reset my password” forms. They subsequently learn their lesson, and go back to using “Collingwood2023!” everywhere, all the time (including as the master password for their password manager).

This is why centralised management is the key to successful adoption of password managers in a small business. When all employees are storing their work-related passwords in the same platform, an administrator can easily reset a user’s forgotten master password (or better yet, set up the password manager for SSO). Centralised management also affords the administrator other benefits like being able to configure minimum requirements for the password generator, and being able to see which users haven’t kicked their bad habits yet (i.e. who’s still using Collingwood2023! everywhere).

Implementation Level 2 - Generate and use strong passwords.

To a lot of people, a password manager is just a “secure vault” to keep their passwords in, so they add all their existing passwords into it, get a quick dopamine hit from the click-to-sign in functionality it gives them, and that’s as far as they go. Can you see the problem here? A vault full of passwords that are all still “Collingwood2023!” doesn’t really move the dial when it comes to protecting passwords. The next step is to get users to start using better passwords, but that’s easier said than done. To put it bluntly, humans are just generally terrible at choosing passwords. Good passwords are truly random, but people like patterns. It doesn’t matter what sort of advice you give, even life-long security goons tend to have some sort of “system” for choosing passwords because it makes them easier to remember… and for the record, the correcthorsebatterystaple method is also crap (because it follows a predictable, predetermined rule).

This is where password managers really come into their own. Firstly, using a password manager entirely negates the need to remember passwords at all. This in turn means no need for predictable rules-based systems to choose them. Secondly, most modern password managers have a built in password generator that’s perfect for coming up with long, random passwords that are impossible to guess or crack with brute force techniques (using current tech and methods at least). Just having this tool available means the next time a user changes any of their passwords, it’s couple of clicks to generate a strong and unique password, save it to the vault, and then automatically enter it into the change password fields. The important thing here is we are making peoples’ jobs easier, not harder.

Furthermore, in a centrally managed tool, the administrator can easily set strong default values for everyone, so everyone gets the same level of password strength, and the user’s don’t have to think about it. OpenCASE doesn’t go so far as to dictate what your password policy should be (though the GUIDANCE does include some tips). The important thing is that you set a good baseline and apply it consistently to everyone. That eliminates the “weakest link” scenario where someone (usually the boss) ends up with sad, easily crackable passwords because they think rules don’t apply to them.

Implementation Level 3 - Perform password audits.

Once you’ve given your users the tools to start adopting good password habits, you’re finally ready to start pushing them to modify their actual behaviour. This is where password audits come in. What’s a password audit? Simply put, it’s a health check against all the passwords used by every person in an organisation to see how secure they are: Do they adhere to policy and general good password hygiene? Have any been compromised? Are any reused multiple times?

How do you even go about that? Isn’t the point of passwords that they’re meant to be secret? Well that’s yet another win you get from using a centrally managed password manager. The vault has visibility of every password that’s stored within. This means it can tell when a user is reusing the same password for multiple accounts, or using a password that’s been exposed in a known data breach. It can also identify passwords that don’t comply with the configured password policy, and it can be made to prompt users to update them so that they do. Best of all, it can do all this without exposing the actual passwords to the administrator (though many still provide this capability separately to account for situations like staff illness or sudden departures).

Conclusion

There’s no denying that passwords are still one of the weakest links in modern cybersecurity, but we also have to accept they’re not about to disappear any time soon (despite what the Passkey Mafia might have you believe). Hopefully after reading this, you’ve come to appreciate that the main reason they’re such a problem isn’t necessarily down to any inherent weakness, but more to do with human behaviour and psychology. Password managers are not a panacea for every password pain point and problem persistently plaguing protection of private or proprietary platforms from the pitfalls people predictably and perpetually plunge into… but they are one of the best tools we have to address the underlying behavioural causes, because they’re one of the few security mechanisms in existence that makes people’s lives easier, not harder.

That’s all for now. Keep your eyes peeled for the coming 2026.07 update to OpenCASE, and I’ll try to get the next episode of “Exploring OpenCASE” out before December….