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

Paper Highlights - A Systematic Study of the Consistency of Two-Factor Authentication User Journeys on Top-Ranked Websites

Link to paper (PDF): https://publications.cispa.saarland/3899/1/Lyastani_NDSS23.pdf

This paper from 2023 looks at how popular websites implement two-factor authentication (2FA) from a user experience (UX) and user interface (UI) perspective. The purpose was to determine the consistency between these sites since that can have an impact on whether users are able to learn about, find, and configure 2FA when they want to. The authors use a metaphor of cars where you have to figure out the braking mechanism every time you want to drive a different model, versus all cars having a standardized brake pedal found in the same location. They argue that added friction to the 2FA setup process causes users to forgo enrollment or leave the web site altogether.

They chose 85 popular websites (like google.com, amazon.com, & reddit.com) and looked at the 2FA experience for each one. The paper discusses general UX design principles and guidelines as they relate to web sites and notes that there isn’t much published guidance specific to 2FA. So this forced the researchers to create their own list of comparison factors which would allow them to methodically categorize everything from 2FA education, feature discovery, setup process, usage, and deactivation.

Commonalities found among these sites were how 2FA was named and described, where it could be found in the account settings, and that it was an optional feature in most cases -- only 7% mandated 2FA use. Of the reviewed sites 49% called it “Two-Factor Authentication (2FA)”, another 28% chose “Two-Step Verification (2SV)”, and only 5% went with the traditional “Multi-Factor Authentication (MFA)” [factor Common-Naming-and-Location].

The authors criticize that the vast majority of sites did not promote 2FA during user account setup, either waiting to nudge users towards enrollment during a later login or other security change. They observed that 73% of the sites provided at least brief information to users about 2FA before the enrollment process started, and another 15% provided a description after enrollment had started [factor Descriptive-notification]. Their premise seems to be that better descriptions may lead to more enrollments. Less of these sites (32%) provided detailed info to help users better understand the purpose of 2FA in protecting their accounts [factor Additional-Information].

Since attackers sometimes attempt to maintain access to hacked accounts by changing 2FA details and recovery emails the researchers also looked at how this was handled. They found 44% of the sites required users to verify their identity before changing 2FA settings [factor Settings-changed-verification], with only 54% informing users of changes after the fact, for instance, by email [factor Settings-changed-notification]. This seems like an area where web sites should improve to better protect and alert users to what may be suspicious changes.

Around 45% of sites allowed users to remember their device, removing or reducing future 2FA prompts from that specific system [factor Device-Remembrance]. But sites implemented this in different ways, sometimes allowing users to opt in (like ‘Remember me on this device’) and other times requiring them to opt out. Most required users to opt in.

76% of the web sites offer 2FA recovery options in case the user can’t authenticate normally (e.g. they lose their phone). Most of those also attempt to explain the importance of the recovery options to their users [factor Informed-2FA-Recovery-Options]. The most popular recovery option was one-time codes that could be printed or otherwise saved offline. Only 7% of the sites forced users to review their recovery options during 2FA enrollment [factor Enforced-2FA-Recovery-Setup].

The authors conclude by encouraging industry associations or other standards groups to formalize better recommendations on 2FA presentation and configuration for developers to rely on. This could bring about more consistency between sites and help users better secure their accounts.

This paper is a pretty dense read in areas, especially if you only have a passing familiarity with UX or UI development, but also offers opportunities to just browse through individual site findings and see what factors applied at the time of this review.

"Hundreds of passwords linked to government departments leaked on dark web"

Link to the article using this headline: https://www.the-independent.com/news/uk/home-news/cyber-attacks-dark-web-government-passwords-leaked-b2832911.html

I don't like this headline because it gives a false sense of how dangerous these few hundred leaked credentials are. The article says a vendor that monitors the dark web found these credentials posted online in the past year and picked out emails that matched UK government domains.

This basically means something like "mthatcher@ncsc.gov.uk : Denis1951" apparently showed up in a breach dump. It doesn't mean that these credentials spilled out from the penetration of a government site, or even that this credential is associated with an account on a government site. The reality is more likely that these credentials were among thousands of other accounts in a breach of a web site not affiliated with the government. They could have been leaked from a small retailer, hobby forum, or restaurant booking site where the employee just used their government email address to register an account.

The paper doesn't ever mention this possibility, instead playing into the narrative that this exposure resulted from government security lapses. Worse yet, when the article writes something like "among the government departments, the most targeted was the Ministry of Justice," this makes it sound like attackers were specifically phishing or otherwise focused on stealing credentials from those government sites. When their expert claims "leaked passwords could allow hackers to access critical systems" that "could" is doing a lot of work.

Now, these credentials could pose a risk to government systems IF those same credentials were reused on a government site that attackers can access. We do know that people often reuse credentials across different sites. Neither the threat intel vendor reporting this data nor the journalists, probably wisely, attempted to determine if this were the case. But I do think this is a good reason for organizations to process third-party password leaks and identify if their employees are reusing exact or similar passwords for their systems. They should also implement effective multi-factor authentication (MFA) so that the exposure of an errant password doesn't lead to a sensitive account compromise.

Link to the vendor (NordStellar/NordPass) report on leaked credentials: https://nordpass.com/public-sector-passwords-leak/

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 

FTC orders CafePress not to store security question answers in plaintext following breach

CafePress is a business that specializes in allowing users to create custom merchandise, like graphic t-shirts, and use their online store to handle sales and fulfillment. After discovering they had suffered a breach in early 2019 the company quietly required users to change passwords while claiming this was due to a password policy change. However, a few months later it became apparent the 23 million record user database containing both buyer and seller customer accounts had been compromised when it was posted online for sale by the criminals, and CafePress was forced to admit they had been hacked.

The US Federal Trade Commission (FTC) got involved as part of their mission to protect consumer privacy and filed an official complaint that highlighted the shortcomings of CafePress. This started a process that would determine what security improvements, ongoing assessments, and fines would be required of CafePress. They issued their final Decision report (PDF) in June of 2022.

Among the many faults outlined in the initial complaint were details of how CafePress didn’t take “reasonable security measures” to prevent the exposure of sensitive user information. The breach had exposed unsalted SHA-1 hashed passwords, security questions & answers, shipping addresses, and US Social Security Numbers (SSNs) for some sellers.

The FTC highlighted the fact that while CafePress had required customer password changes following the breach they didn’t force changes to security question answers. And these security questions were used for account recovery. It appears that after requesting a password reset the users were prompted with their security question and allowed to change their password directly after answering it correctly, without any email verification needed. So the original attackers, or anyone else that had obtained the stolen data, could perform account takeover (ATO) by plugging in leaked email addresses and security question answers.

Related to this problem, the FTC highlighted that storing these security question answers in plaintext was not adequate protection. But if CafePress could hash passwords -- albeit poorly -- then why were the security question answers stored in plaintext? The short answer is that most information in databases is stored in plaintext by default. Unless someone involved with the software development process identifies that this practice is either too risky or that it fails to comply with laws/industry standards then that data is likely to stay unprotected.

The slightly longer answer is that some of the systems that manage security questions do expect to have plaintext access to their answers. Unlike passwords that tend to require exact matches, answers to security questions are sometimes given more leeway as long as they are close enough to the expected answer. For example, the question “what was your first address” might be answered “123 First Street” or “123 1st St” depending on how the user is recalling their address. Some systems even accommodate different character capitalizations “123 first street”, typos like “123 Frist Street”, or missing words “123 First”.

There are also situations when the same security questions used for online access are also asked by customer service representatives talking to customers over the phone or in person, possibly requiring these personnel to see the customer’s answer to check it for correctness.

So when hashing answers is not possible, what is the alternative? These answers could be encrypted before storage. Encrypting these records (along with proper key management and access controls) could allow the answers to be decrypted and checked when necessary without exposing them to any attacker with read access to the database.

Interestingly, the FTC didn’t actually recommend that CafePress encrypt their security question answers, but ordered them to get rid of the questions altogether. They wrote that multi-factor authentication (MFA) alternatives should replace this functionality. I’d argue this directive doesn’t clearly address the issue of account recovery, because that can still be a problem even with MFA, but it does eliminate reliance on security questions as the sole gatekeeper of the recovery process.

If you are going to continue to rely on security questions it seems like you should avoid some potential legal and financial trouble by protecting their answers with encryption, as well as force users to change them if you ever suspect the data has been compromised. Then you just have to deal with all the other problems of security questions.

Meta fined €91 million for accidentally storing user passwords in plaintext

Meta (parent company to Facebook, Instagram, and others) was just fined €91 million by the Irish Data Protection Commission (DPC) due to an apparent oversight that allowed user passwords to be stored in plaintext. While technical details about the exposure are limited, this seemed to be a situation where these passwords were logged in plaintext outside of the normal account database. Passwords stored there were properly protected with scrypt, according to Facebook.

The company reported they had not detected any outside access to these passwords nor any abuse of them by internal personnel. Despite this reassurance, the DPC decided this exposure still threatened people's potentially sensitive social media accounts with takeover or abuse, and constituted a breach of personal data under the European General Data Protection Regulation (GDPR).

Facebook actually identified and self reported this mistake following an internal security review back in early 2019, but the gears of government have been slowly grinding since then to produce a final ruling.

This does serve as a good reminder that once you have your passwords properly secured in the user database you should assess where else they might leak. Web access logs, error logs, caches, and other similar systems might inadvertently expose plaintext passwords to those who would seek out an easier way to capture them.