"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.

Paper Highlights - Do Password Managers Improve Password Hygiene?

PDF of paper: https://dash.harvard.edu/server/api/core/bitstreams/9f5f14ef-7009-46ba-9315-6ba02e625bbe/content

We’re no strangers to recommending password managers, typically because we hope that installing the software will also lead to people using strong and unique passwords.  The 2022 paper "Do Password Managers Improve Password Hygiene?" attempted to measure how closely these password practices are actually associated with the use of password managers.  

The researchers found an initial pool of around 5,000 online participants to survey about their use of password management software.  They eventually filtered this down to a much shorter list of people (n=142) who had validated their use of a password manager that included both ‘hygiene’ reporting and storage or more than five passwords.  These hygiene reports provided some details on each user’s overall password strength, reuse, and compromised status.  The researchers relied upon these reports and survey question responses to reach their conclusions about participant password practices.

Since master passwords are key to protecting access to a password manager’s data the researchers asked how participants generated theirs.  About 54% said they had generated a new password in their heads, while 35% reused a password they had already memorized.  Less than 10% reported using a random password generated by their password manager or another random process. [Q3] When choosing what should probably be your strongest secret, we really need more people opting for a strong, random password or passphrase. 

This trend of wanting to use a password manager but not wanting it to generate every password continued for many study participants.  Around 54% of the participants indicated they were more likely to create a password themselves and just let their password manager store it. About 44% said they allowed the password manager to both create and store their passwords. [Q16a]

The researchers did divide reported data between people using Chrome for password management and people using third-party solutions (e.g. 1Password, Bitwarden, etc.).  This was one area where differences between these participant groups stood out. 79% of Chrome password manager users were still choosing passwords themselves compared to 36% of third party password manager users.  Accordingly 62% of third party password manager users allowed their software to generate random passwords, compared to only 21% of Chrome password manager users. [Q16a]

This may indicate that a lot of people still want to use passwords of their own creation, possibly because they’ll remember them better, and just have the password manager as a backup in case they forget them.

One purpose of the hygiene reports included with some password managers was to provide feedback to users on their password security so that they would take action to change highlighted passwords.  But it seems that some users didn’t understand this feature.  When asked to identify one or more reasons why they still used passwords identified as weak or reused, 35% said they were not previously aware of that classification.  Around 36% said they were overwhelmed by the amount of work needed to replace these passwords.  And 35% responded that they just hadn’t gotten around to replacing them. [Q10]

Even fewer participants seemed to know when their passwords had been reported as compromised, with 52% indicating they weren’t aware they had been exposed.  The popular reasons for not replacing these passwords were similar to the reasons they had for not replacing their weak or reused passwords. [Q12]

Password managers can only do so much to encourage password changes, although some have implemented features aiming to speed up the process for select websites.  This challenge isn’t likely to become much easier unless the web adopts a standardized mechanism for automating password changes that password managers can then implement.  It also seems hard to motivate users to care more about changing their bad passwords. A different study in 2024 found only slight improvements in password changing behavior after implementing nudges to convince users to do so.

The researchers for this paper do note that password weakness or reuse are not necessarily indicators of users making bad decisions if these issues only affect low value accounts.  Participants were asked why they thought it was okay to have weak or reused passwords and 49% confirmed that they didn’t feel these accounts were worth protecting better.  Another 40% said they needed these passwords so that they could remember them without their password manager. [Q9]

Participants who were screened out due to not using a password manager (n=1,315) were asked why they didn’t use one. When offered one or more options 58% selected that they were concerned someone else could access their computer or device storing the passwords. Another 46% were worried that malicious software might compromise their device and also their passwords.  28% indicated that they distrusted developers of password management software with their passwords. But they don’t indicate if this is because they suspect the developers themselves of malicious intent, or suspect them of being unable to properly secure the software against attack by others. [Q2]

This report includes more feedback relating to people's use of password managers, and I’d encourage you to browse through the paper to find more interesting data points on your own.

PDF of paper: https://dash.harvard.edu/server/api/core/bitstreams/9f5f14ef-7009-46ba-9315-6ba02e625bbe/content 

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.