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 

Thoughts on new authentication guidance in OWASP Application Security Verification Standard (ASVS) v4.0

[This content was originally posted in a series of tweets, but it also made sense to share it here.]

OWASP released v4.0 of the Application Security Verification Standard (ASVS) in March, listing security practices for organizations to design, code, and test apps against. There were substantial content changes in the authentication section, so after reviewing it I wanted to tell you what I thought about the changes.

The authors state in the V2 Authentication Verification Requirements section that their goal is bringing this standard closer in line with significant authentication changes published by NIST in the SP 800-63 Digital Identity Guidelines update that came out after ASVS v3.0.

There are 57 requirements in section 2 for ASVS version 4.0, compared to 26 in the same section of 3.0, which more than doubles the number of previous requirements.  Around 9 requirements are seemingly removed in 4.0. So let's go through some of the notable changes to the standard.

Requirement 2.1.1 establishes a minimum password length of 12 characters for users, which is one big divergence from NIST’s minimum of 8 chars. While this is justifiable for security, I do think it will cause protests, especially if dealing with third-party or legacy apps that have hard-coded lower length settings.

2.1.4 asks for support of Unicode characters in passwords. Another good change, and while I don’t have statistics I suspect a large number of Internet apps can’t meet this requirement today. Many of them are still struggling just to allow symbols (see @PWTooStrong).

2.1.6 talks about verifying the old password to select a new password, but removes text from older standard about new password confirmation. I suspect that with the addition of 2.1.12 saying to add a password field unmasking option that OWASP made this change for usability (see Why the Confirm Password Field Must Die).

Requirement 2.1.7 expands on previous guidance to prevent use of common/weak passwords to specifically recommend use of a 1,000 - 10,000 entry blacklist, either maintained locally or transmitted securely using a third party like @haveibeenpwned or Azure AD Password Protection.

2.1.9 says to eliminate any password complexity policy requirements or restrictions. This places responsibility on blacklists and minimum password lengths to prevent bad password choices. It's a very contentious change for orgs who've used complexity policies for decades.

Speaking more generally, the migration away from password complexity policies to blacklists is a major shift that needs additional research. If you implement password blacklisting within your org please find a way to share your lessons learned, anonymously if needed, so we can all benefit.

New requirement 2.1.8 says to provide a password strength meter to guide users towards choosing stronger passwords or passphrases. However, not all meters are created equally, so I recommend taking the time to select a good one (see On the Accuracy of Password Strength Meters)

2.1.10 instructs the removal of password expiration policies, which has gained support in recent years. But this goes hand-in-hand with requirement 2.2.1 to implement controls to combat password attacks and reduce the chances of a password compromise leading to account takeover.

Requirement 2.2.2 discourages relying on ‘weak authenticators’ like SMS and email. 2.2.4 and 2.2.7 advocate prioritizing reliance on MFA options less likely to be compromised, like OTP tokencodes, U2F security keys, or client-side certificates.

2.2.3 says to securely notify users following any changes to their credentials, emails, addresses, or if new logins to their accounts occur from a riskier/previously unknown location. The use of push notifications is preferred to better direct user attention to these events.

Requirements in 2.4 expand OWASP guidance on password storage to include aspects like salt randomness and length. But they don’t mention Argon2 or scrypt, instead offering work factor advice for bcrypt and an oddly inflated PBKDF2 iteration count of 100,000 (NIST is satisfied with 10,000).

They do discuss Argon2 and scrypt in the OWASP Password Storage Cheat Sheet, so it’s likely these documents just need to be aligned better. The PBKDF2 iteration count discrepancy may just be a typo.

2.5.2 now calls for the elimination of security questions rather than just making sure the ones in use are ‘good’. Many industries, especially US banking, still rely on these for secondary authentication. But with stronger MFA options OWASP thinks they can be phased out.

Sections 2.6 and 2.7 are brand new and describe recommended security elements for Transaction Authorization Numbers (TANs) and out-of-band (OOB) authenticators. These tie back directly to NIST guidance for designing or implementing these solutions.

Section 2.8 likewise gives guidance on one-time password (OTP) authenticator use, with section 2.9 discussing cryptographic security key authenticators (FIDO U2F). You may not develop these functions in-house but should validate that your vendor has done so properly.

Section 2.10 adds further guidance on storage of passwords or API keys used by application code, including not to “rely on unchanging passwords”. I think a better word would be “unchangeable” so they should be updated as needed but not on a set schedule.

So what was removed in section 2 of the new 4.0 ASVS? Some practices in the old standard may have been considered too basic, such as ‘require authentication for anything non-public’, ‘enforce authentication on the server’, and ‘fail securely to a default deny.’

The old 2.2 is removed which stated “Verify that forms containing credentials are not filled in by the application.” This could be understood to include password managers autofilling credentials, rather than just browsers, which OWASP may have decided to no longer discourage.

One absence is the old 2.23 practice of making sure account lockout due to login failures was flagged separately from administrative account disabling. It was a logical recommendation, so I don’t know if it was also considered too basic or whether it's removal is an oversight.

Also removed is the 2.28 guidance to ‘make sure all authentication challenge responses take the same time.’ Intended to prevent things like timing attacks that leak credential info, this may have been thought to be too difficult to implement consistently for the value it provided.

Old practice 2.32 wanted you to make sure administrative interfaces weren’t accessible to untrusted networks. This may have been removed because it becomes more difficult in a cloud-hosted world, or maybe because some apps use the same login interface for admins and normal users.  [project lead Andrew van der Stock commented "We did that because "where" is not as important as "who". The idea of Fortress Admin is laughable and always has been. Let's move beyond layer 3 restrictions."]

Finally, gone is the old 2.18 requirement to verify that username enumeration isn’t possible in login or account recovery functions. While preventing account enumeration is good, it tends to provide little value at the expense of the user experience.

I created a Google spreadsheet to compare the section 2 authentication requirements of the ASVS 4.0 and 3.0 side by side. You can access it here: https://docs.google.com/spreadsheets/d/1UbOsbgv4WsmuVuL8M3NoCRD7UQKAw7vl6BLYaLk-EtI/

Wrapping up this review, I want to thank the OWASP organizers and volunteers who developed this standard and made the tough decisions about what practices to include/exclude. Project leads include @vanderaj @JoshCGrossman @dcuthbert @m8urnett & @manicode.

My advice to users on storing written passwords

Giving blanket advice on creating, using, and securing passwords is always a worry of mine. Life has taught me that advice is sometimes interpreted or adapted in such a way that it is, at best, rendered less useful or, at worse, made downright dangerous. This is more likely to happen as the subject knowledge gap expands between the advice giver and advice receiver.

So, it was with some hesitancy that I shared my advice on writing down passwords with a reporter a few weeks ago. To his credit, the quote he included in his article was intact and hadn't fallen victim to creative rephrasing. However, I knew that some of his readers would be absorbing my advice from a non-technical perspective and I worried about their interpretation. I would like to use this blog post to explain this advice beyond the few lines available to me in his column.

Let's start with the quote: "This is controversial advice in some circles, but I advise people to write down their passwords. If it is a password you are going to use every day, keep it on a slip of paper in your wallet. Don't write anything else down on the paper that could identify where you are using the password or your username."

I believe this is sound advice, although I want to emphasize the importance of writing passwords on a blank piece of paper with no other identifying information. Once during an introduction I was handed a business card which included a string of characters written on the back. The string struck me as particularly password-like. I can only assume the person had written it down and forgotten that this particular card wasn't meant to be given away.

What didn't make it into the article was my subsequent comment that a password in your wallet should serve only as a temporary memory aid. Within a week or two of use, a password should be committed to long term memory, reducing the likelihood of it being forgotten. This is when the wallet copy should be destroyed and the password archived in a more secure location.

I will avoid getting into specific password storage software in this post. There are good open source and commercial alternatives available. There are also Trojans horses posing as password managers that would love nothing more than to capture your secrets and relay them back across the Internet to their criminal masters. Take time to check out the reputation of any password software before installing it.

I recommend writing down passwords to improve their usability and affordability by reducing the number of times a forgotten password results in an IT support call. However, the biggest benefit is the chance to encourage better password selection.

One of the major factors that impede good password choices is a user's fear that they won't remember a well constructed password. Nobody wants to be stuck staring at a password prompt and cursing their decision to finally come up with a good password. Even worse is the feeling of stupidity they experience when they have to call someone and admit to forgetting their password.

When a person has a reliable written record of a password it takes away a lot of this fear by letting them serve as their own first line of support.

If you are willing to publicly support this practice in your organization, I encourage you to associate this freedom with a requirement for stronger password security. Educate users on how to construct hard-to-guess passwords. Implement technical controls that force new passwords to meet minimum requirements. Make sure that passwords are changed on a regular basis. Finally, emphasize that these written or stored passwords must be very well protected.

Does this practice seem practical for the people you work with, or am I only encouraging a new generation of people to sticky-note passwords by their computers?

How password policy requirements impact possible password choices

A recent discussion on a SecurityFocus.com mailing list raised a concern about password policies that I hadn't previously given much thought to. The post author commented that he wanted to enforce a policy that required passwords to have lowercase, uppercase, number, and symbol characters. By this he meant every password must have at least one character from each of these characters sets. One reader responded that by requiring the use of all four character sets he would reduce the total number of possible passwords, causing a negative impact on password security.

Instinctively I knew the claim about reducing password possibilities was right, but I dismissed the security impacts as insignificant. After all, with 95 standard characters within that character pool to choose from, the total number of password possibilities is massive. Unfortunately "massive" doesn't really provide much perspective on how negative the impact could be. To quantify the impact I decided to calculate the actual effects on password possibilities.

I started with a set password length of 7 characters, giving us 95^7 (or 6.98 x 10^13) total possible passwords that users can create without any specific character requirements. This gave me the unrestricted total. I then needed to figure out how many of these passwords would meet the restricted requirements of having lowercase, uppercase, number, and symbol characters within them.

Following some different approaches at number crunching I found that there may not be an easy formula for calculating the quantity of restricted password possibilities. The easiest approach seemed to be counting the number of passwords not meeting the criteria and then subtracting them from the unrestricted total. While not math intensive, this approach does take some fancy spreadsheet formulas. If you have a burning desire to see the numbers yourself, you can check out the resulting Excel spreadsheet I created.

When I compared the restricted and unrestricted password possibilities I was in for a bit of a shock. It turns out that for 7 character passwords the restricted requirements would eliminate about 63% (or 4.4 x 10^13) of the total password possibilities! So much for an insignificant impact.

I applied this technique for several different lengths of passwords to see how the length changed the results. The longer the password became, the more the percentage of eliminated passwords shrunk. The restriction eliminated 54% of 8 character passwords. With 10 and 12 character passwords only 41% and 31%, respectively, were eliminated. These losses still amount to sizeable chunks.

This led me to evaluate the impacts of the normal Microsoft Windows password complexity requirements. Enabling this security policy forces users to choose a password made up from only three of the four character types. For a 7 character password this still amounted to a 9% reduction in possible passwords.

So, numerically we've established the impacts of different password policies, but how should these numbers affect our decisions to enforce such policies?

If we consider password cracking our biggest threat then we must consider how knowledge of the password policy might save an attacker time avoiding unacceptable passwords. Fortunately, real-time brute force cracking isn't terribly compatible with this approach. In the time it takes for cracking software to evaluate whether a password guess meets the policy it could have just tried the password. So no effort is eliminated in this scenario.

However, a rainbows tables cracking approach can benefit from policy knowledge. An attacker could create a rainbow table consisting of only the passwords that meet a particular password policy. As a matter of fact, attackers do that today by generating and sharing rainbow tables consisting of the most common password character sets.

While bad guys could technically implement this attack for complex passwords, it would be one of last resorts. So few environments require passwords containing the four different character sets that attackers have little reason to generate the rainbow tables. It is still much more rewarding for them to focus on cracking passwords like "muffins" instead of "b@n4Na5".

More importantly, creating just the rainbow tables needed for our restricted password pool of 7 character passwords would require hundreds of terabytes of disk space. Yes, I did the math. Few attackers have this level of resources available to them.

We have always made sacrifices like this when instituting password policies. By establishing a minimum password length we, by definition, eliminate all possible passwords of a shorter length. Nonetheless, we know we are making a general improvement in overall password security by removing the shorter, and thus easier to crack, passwords.

When it comes to password complexity we have to consider the attack significance along with the mathematical significance. In reality, there are situations where enforcing specific password restrictions is a very bad idea. However, this is the exception rather than the rule.

I don't believe that enforcing either normal Windows password complexity policy or the even more restrictive 4 character set composition requirement should worry you when paired with a minimum password length of 7 characters. The loss of possible passwords in these cases are greatly outweighed by the benefits of eliminating a large number of poor password choices. From my perspective, those changes have a positive impact on security.