CERN accelerates towards usable security with new password policy

CERN is a European organization that hosts scientific research and labs for experiments, like the Large Hadron Collider. Their network connects the scientists and staff needed to support these research efforts. Despite being based in Switzerland CERN recently announced changes to more closely follow guidance from the US NIST SP 800 63B standard on user passwords in their environment.

These changes included removing password character complexity requirements and establishing a minimum password length of 15 characters. This latter measure is typically adopted to eliminate the more often guessed short, common passwords and encourage the use of longer passphrases.

With password character complexity requirements no longer in place to encourage difficult-to-guess passwords CERN will instead rely on two blacklists of forbidden choices. The first is composed of simple passwords (like ‘123456’ and ‘CERN2025’), and the second contains “burnt” passwords. These so-called burnt passwords are publicly known by at least some password hackers. CERN learns of these by using the HaveIBeenPwned database and other repositories of passwords publicly exposed through data breaches.

CERN had already stopped forcing regular password changes with an annual expiration policy back in 2020. At that same time they’d implemented an adaptive password policy similar to the one the University of Pennsylvania recently adopted. Why that policy has now been simplified further to just a minimum password length isn’t discussed, but it may be to further reduce user confusion about how to create a compliant password. CERN was finalizing their deployment of Two-Factor Authentication (2FA) to users last year, so the security added with that change may have also reduced the need for a strict password policy.

Link to announcement: https://home.cern/news/news/computing/computer-security-password-evolutions

Ohio State University Eliminates Password Expiration With New Passphrase Focused Policy

Similar to the recently discussed University of Pennsylvania policy change, Ohio State University (OSU) is also updating their password policy for students and faculty. They announced that they’re eliminating their current password expiration controls that required regular password changes every 180 days. The University shared that this change should save both their users and the IT department time and money previously spent helping people who forgot their new passwords following a mandatory change. They also hope this new policy will lead to fewer users recycling weaker passwords by making only small changes (like going from “Buckeyes1” to “Buckeyes2”) when regularly forced to choose new ones.

So how is the organization planning to preserve password security following this change? Similar to Univ of Pennsylvania, they are increasing their minimum password length to 15 characters with a maximum of 128. This is to encourage users to move away from shorter passwords to passphrases in hopes that these will be easier for users to remember while being harder for attackers to guess.

They are also pairing these passphrases with an existing multi-factor authentication (MFA) mobile app. While they don’t share details on whether MFA will be required during every login, they could only prompt for it when people log into their account from a new device or otherwise exhibit riskier behavior.

Finally, the university says that they will be monitoring passphrase use for signs they have been cracked or otherwise stolen. This seems to include watching for third-party breach data dumps that may include credentials used by school users. Then their security team can force a password change when it really matters instead of when the calendar says to.

Link to policy change news: https://it.osu.edu/news/2025/10/09/new-password-policy-enhances-security-and-convenience

Paper Highlights: Investigating the Password Policy Practices of Website Administrators

This paper, "Investigating the Password Policy Practices of Website Administrators", was presented at the 2023 IEEE Symposium on Security and Privacy conference. But I ran across it today and thought it provided some helpful insight into why people developing or maintaining web applications chose certain password policies. The research team interviewed a small sample of 11 US-based professionals who had experience setting or managing website password policies in order to learn not just what decisions they made, but why. These weren't necessarily dedicated security team members, but more likely developers or system administrators.

A few highlights from my read:

Password composition restrictions (e.g. what characters or what length can be used) were often a result of a compatibility requirements with existing systems at the organization. Some of these restrictions affected common symbols (e.g. "&" and "?"), but others were probably extended ASCII or Unicode characters.

One organization was still limiting passwords to 16 maximum characters because of the contentious logic that 'limiting the length was necessary because users often forgot long passwords'. A couple others didn't place any limits on maximum length.

7 of the 11 respondents said they were still enforcing password expiration despite some industry guidance starting to discourage this practice. They seemed to think this provided needed protection against account takeover (ATO) from leaked or shared passwords. Those who didn't force expiration referred to their concerns that regular changes caused more user frustration and felt their systems were secure enough to withstand password attacks.

About half the participants mentioned looking either at industry standards (like NIST's 800-63B) or the practices of other large Internet sites (like Facebook or Google) for guidance on forming their own password policies. A few cited legal or industry compliance pressure forcing certain settings.

There are other interesting disclosures, like whether these organizations blocked certain passwords (e.g. blacklists) and how they decided what passwords to block. But I'd also like to hear from those of you who have been involved in this process yourselves. What steered some of your decision making?

Paper link: https://www.computer.org/csdl/proceedings-article/sp/2023/933600b437/1OXGTWy2ktq