On enforcing password changes: Don't!

I’m hopeful that passkeys will end up being a solid solution to the UPPERCASE lowercase number symbol dogs-name-mothers-favourite-movie-last-place-you-saw-a-sunrise nightmare we live in.

Good to see Microsoft have this in production for Azure AD now

1 Like

Thanks @derek.b for taking the bait ;p
Yes I could give a brute-force a go - but then I’m left with an anecdote so hardly better than expert opinion.

Seriously though, context is important - the password isn’t the only line of security where I work e.g. you also need access to hospital network. How does that alter the risk of a successful malicious attack? Where’re the data? Even something small like password change frequency: my DHB forces my 8 character password to be changed every 3 months. Where’s the evidence for that particular aspect? Is 2 months better? 12 months? Does more frequent change lead to reduced likelihood of a successful password attack and consequently negative impact on patients, but more need for resetting forgotten passwords and interruption to workflow and consequently negative impact on patients? Is this evidence-based or just ideology? Can we get comparative data from the natural experiment of different password policies employed around the 20 DHBs over the years?

THanks @derek.b yeah the bait comment was tongue in cheek, other than I’ve asked about empiric data previously on the topic of passwords somewhere in these forums and don’t recall any reply with empiric data. Your extensive response is thoughtful, but unless I’m missing something, it’s largely bereft of empiric data?

Standards (e.g. NZISM) and mechanistic arguments (e.g. defense-in-depth approach being superior to single layer) are great, but given these policies come with costs (including to clinicians), it’d be useful to see how implementing these policies perform in the workplace with systematically collected data.

I agree with your point about the changing context within which these security policies operate can make it difficult to interpret the data. However, this problem is something healthcare has grappled with for a long time: a randomised controlled trial may show that medicine X saves lives in people with heart disease in 2002, but 22 y later the context in which that medicine is used has changed and maybe it doesn’t have the same impact that it used to have, maybe in some groups of individuals with different cultures and genetics its impact is variable. That’s dealt with by collecting and examining data through the years including the varying contexts. The 23&me example (I agree it looks bad to be blaming your customers!) is a bit of empiric data, but only a bit: regarding the breach per se, this is akin to having a surgical procedure that’s been done for years having a single severe adverse incident and the judgement is “that’s bad” in the absence of any other data regarding the benefits and harms regarding the procedure.

But mayhap the paradigm in which password policies operate regarding evidence is that empiric data are just not examined? (for whatever reasons)

Paul, have you done a literature search on this topic? I did in the past, but found things quite sparse. But I didn’t dig very deep.

Certainly, there is ample 3rd party evidence provided by the fact that all major cloud based IT services (Apple, Google, Amazon, etc etc) moved away from enforced password changes about 15 years ago. They would only do this en masse if there were serious financial and cybersecurity advantages in doing so. They are robust on these fronts (and care about money a great deal!).

We’ve been pretty darn slow to follow their lead in Digital Health - and certainly have zero evidence to support the common (in DH) position of password change enforcement!!

Later…

I have managed to find a bit in the international literature about this whole thing, such as this:

https://dl.acm.org/doi/full/10.1145/3544548.3581410

This contains the statement:

Some misconceptions are prevalent around the world , e. g., “It is important for the security of my user accounts to regularly change the password.”

Here is a paper describing the situation of sluggish implementation of the same type of guidance that we have here in NZ, but in Germany (from here):

soups2023-gerlitz-evolution.pdf (508.5 KB)

And lastly, Microsoft’s own password guidance also strongly recommend that passwords do not expire (and this is the default for any new domain):

The evidence is out there - but it isn’t served up in a lovely Cochrane-style systematic review as we might prefer in medicine!

THanks @NathanK for an extensive response. I hadn’t done my own literature review - this isn’t my area of expertise so was hoping someone else had this literature at their fingertips (i.e. not just another enthusiastic amateur like me who might go down the wrong literary rabbit hole!).

That paper from Bonn comprises surveys of what people do, rather than
a) data supporting why they do it
b) data describing what is the impact of what they do (good and bad)
However, it does mention https://www.researchgate.net/profile/Angela-Sasse/publication/221517955_The_true_cost_of_unusable_password_policies/links/02bfe513788eed0105000000/The-true-cost-of-unusable-password-policies.pdf which is another survey of experiences but gives some insights to highlight some lines of inquiry to subject to quantitative analyses.

That 3rd party evidence you mention is of some value. But it’s a bit like the notion that oxygen is given to everyone presenting with a heart attack, which was a standard part of management for years, until some systematically collected data showed that it was not usually a useful thing to do. Might the same thing be happening with password policies? Or maybe these empiric data are just not published in the public domain??

I get your point about Cochrane systematic reviews, but I’m used to the absence of this in my line of work where most of the clinical questions I deal with haven’t been subject to systematic reviews.

I just saw this video on Facebook and it reminded me of your Michael McIntyre sketch!

Hopefully they dont do this in the healthcare system…

I’ve just had the pleasure of an enforced password change inflicted up me for my Health NZ | Te Whatu Ora Southern locum work. It is still clearly a thing (despite all the cybersecurity advice to the contrary).

It basically compromises 1/2 an hour of clinical work each time it happens, and a fair chunk of IT support time too (as inevitably it takes a few steps, and MedChart isn’t keyed into AD down there). My blood boiling is another SE (fortunately, this settles down after an appendicectomy or two).

Is anyone else out there still being driven nuts by this? Or is it just intolerant me?

How can we effect some positive change in this area - especially within Health NZ?

How are the appendicectomy patients? Did your boiling blood strengthen your attention?

Nah, seriously, there is an ongoing debate about strong passwords vs passphrases and other tech to keep information systems safe. It’s a policy (political?) decision and needs some robust debate (IMHO) to settle the outcome…until a new threat appears or new tech appears to protect us against new threats.

5 posts were split to a new topic: CAPTCHA, mouse movement, and AI

The debate over enforced password changes was settled at least a decade ago!!! A nice example:

Current NZ situation

Yes, agree that there isn’t currently a super clear consensus as to the best way to ensure secure access at present. However, what we do have is some pretty clear and helpful authoritative NZ government advice (which has been recently updated):

https://www.cert.govt.nz/information-and-advice/guides/manage-authentication/

Key secure authentication takeaways

  • Identifying all the authentication methods used for all the hardware and software in your environment can be hard and time consuming. Prioritise this work by looking at any internet-facing or business critical services first, then working on the rest.

  • Each of these authentication security controls protect against different attack techniques. For example, MFA is a key control for protecting internet-facing or high value accounts from brute force or password reuse attacks. Changing default credentials is a key control when you are rolling out vendor-provided software or hardware that is known to come with out-of-the-box credentials to get customers started. Securing your cloud identity provider system is a key control to prevent attackers from bypassing other controls, like MFA. Each of these controls address different risks which is why it is important to implement them all to make your authentication methods secure.

  • If there’s a system that doesn’t allow you to set up MFA, assess the risk of unauthorised access. If they are accessible over the internet, then they’re at a much higher risk of unauthorised access. You may want to consider alternative systems that do allow MFA instead. If alternative systems aren’t possible, place the system behind another that allows MFA, such as a VPN or MFA-enabled web proxy.

  • Some MFA methods are easier to bypass, like codes sent by SMS. Prefer hardware or software tokens over SMS MFA if available. If a notification by SMS is the only method available it is better than not having it at all.

from https://www.cert.govt.nz/information-and-advice/guides/manage-authentication/

Agree. The evidence is there that regular changes to passwords isn’t the best way to do security. It’s analogous to changing your house key every three months. However, I would like to shout out to our cybersecurity people who are doing their best in the creaking health sector at the moment.
Let’s hope they take advantage of the current climate and find ways to reduce user burden by simplifying the password system as soon as they get the opportunity.

1 Like

Security is vital, with phishing attacks of various sorts being depressingly effective, at times even the informed and wary get caught out.

CAPTCHA can be spoofed by AI in various ways now, and mouse movements, which are the truth behind the lie of “spot all the bicycles”, can also potentially be spoofed. If humans can design it, humans can circumvent it, given enough time and motivation. Security needs to put off the casual drive-by hack, most things beyond that run into the memory and cognitive limitations of wet-ware.
One thing has always bothered me, why do I get a maximum of 3 to 8 goes at a log-in before being locked out, yet software attacks can have millions a minute? Seems like someone in law-enforcement/government/IS wants to preserve their ability to get around the safeties…

Paul, (@paulchinnz )

How about the ‘Imprivata’ implementation we did at CDHB?
Login once a day to identify yourself (ie. Something you know)
then use the Imprivata’ card (something you have) to bring your session to your current location?