Hackers arrested for guessing thousands of home IP surveillance camera passwords and capturing intimate videos

Four Korean suspects have been arrested for collectively hacking into over 120,000 IP surveillance cameras, allegedly by guessing the simple passwords chosen to protect them. These people acted independently, but they all appeared to have the same motive of capturing sexually intimate videos from cameras installed to monitor the interiors of victim's homes. Two of them were also caught then posting hundreds of these stolen videos for sale on a porn website.

Link to article: https://koreajoongangdaily.joins.com/news/2025-11-30/national/socialAffairs/Four-arrested-for-hacking-surveillance-cameras-to-produce-pornography/2466324 

 

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.

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.

When Should You Change Your Password?

May 7th is known as Password Day on the Internet.  The annual event is used to draw attention to common password problems and offer tips to people for choosing and managing passwords better.  Found among this advice is guidance to change your passwords on this day, or to at least change them regularly. Unfortunately, this practice it isn't as clearly beneficial as those offering it might hope.

The reality is that we security professionals have been advocating regular password changes, and sometimes forcing users to comply, for decades with very little evidence that it is useful.  The only reason to change a password is if we know an attacker has obtained it or if we suspect this is likely.  We simply don’t have data that shows regular password changes do make an impact on the problem of password theft.

I gave a presentation on password expiration for a technical audience at PasswordsCon last year, but it didn't address the challenge from a user's point of view.  So, I wrote this related article for the average Internet user, and not only technology or security industry veterans.

With that background, here are the questions I would ask yourself before changing your passwords.  I've listed these from the most important questions to the least important.

Has a company told you that they've had a security breach and recommended you change your password?

Usually responsible companies will alert users if they have suffered a security intrusion that put user passwords at risk.  This alert will hopefully come in the form of an email or letter to you, but might also show up as an notification when you log into their site.  Some sites force you to change your password following a breach, while others simply recommend you change it and leave that decision up to you.

On some sites your stolen password may be cryptographically protected, but this may only buy you a few days or weeks following a breach before attackers can 'crack' them and start using your account.  I recommend quickly changing your password in any situation where you've been alerted there was a security breach.

If you have used this same compromised password on other sites you should also change those passwords to a new value since some attackers will try to use your credentials everywhere they can.

Have you noticed suspicious account activity on a site?

Sometimes noticing suspicious activity with your account on a site is easy.  If you see posts on your Facebook account that you didn't make, that’s a pretty good sign something is wrong.  Likewise, unfamiliar purchases or other financial transactions on an account is a red flag.

But other times there may be more subtle clues that you’ll have to search for.  Are messages marked as read when you haven’t reviewed them?  Was the last account login time recorded when you weren't using your account?  Has your email address, phone number, or home address been updated to an unfamiliar value?

Some sites are very good about helping you notice unusual behavior, such as when someone logs into your account from a new computer or device.  These companies might send you an email to alert you of this behavior or of sensitive changes to your account.  While scammers sometimes fake these emails in ‘phishing’ attacks, you can often avoid clicking links in suspicious emails and log directly into the site to see if the warning is legitimate.

If you see reasonable signs that someone else has been using your account then this is also a good time to change your password.

Have you logged in from a shared computer or had a virus since your last password change?

Shared computers are the type you might find in a library, school, Internet/gaming cafe, or hotel.  They aren't owned by you and they typically don’t offer much reassurance that they are secure against malicious tampering.  An attacker can install software to capture any passwords you type while on the computer, and then use that information to later impersonate you.

If you want to log into a site while on a shared computers then consider changing any passwords you used once you are back on a trusted computer or mobile device.  Otherwise you might want to avoid shared computer use altogether since there’s a chance an attacker can carry out their crimes before you have time to change passwords.

If your computer or mobile device has been infected with a virus or other malware there’s also a good chance your passwords were captured during the infection.  Once you are certain that the malicious software has been removed you should consider changing any passwords that were exposed.  If you still have malicious software on your computer then simply changing your password may not help. The criminals will be able to capture your new password when you type it in and they can continue to misuse it.

If you aren't sure how long your computer was infected, and thereby what passwords are at risk, it might make sense to change the passwords of your most valuable accounts first and monitor your less valuable accounts for any sign of suspicious activity, changing more passwords as necessary.

Have you shared a password with someone who you no longer trust or who you may have trusted too much?

While you generally shouldn't make a practice of sharing your passwords, there are times where you probably will.  Maybe a significant other needs to read important messages for you while you’re out, or you share an account for a service that the whole family uses.

Problems with this habit tend to arise when either a breakup or other relationship distress occurs that changes how much you can continue trusting the person with your password.  Amidst the usual stress of these events it is still important to take the time to think about what accounts are now exposed to potential abuse and to make password changes where needed.  Even if you part on good terms, it can still be a good idea to remove the possibility of someone’s curiosity or jealousy later tempting them to get into your accounts.

Other situations you should be careful with are people who ask for your password with seemingly legitimate motives that you later begin to distrust.  For example, maybe you get a phone call from someone representing a company that claims to be fixing a problem for you but needs your password.  Or maybe a coworker or fellow student is working on a project with you and needs your password to access shared information.

In these situations you might comply with the request initially and realize after the fact that it probably wasn't a good idea.  Change these passwords and think about how to avoid these situations in the future.

Have you used this same password on another site that is much less valuable?

Another common password recommendation is that you use a unique password for every site you log into.  This recommendation it is very helpful in limiting abuse of your accounts if you choose to follow it.  However, many people share passwords between at least some of their accounts to ease the burden of memorizing a long list of secrets.

If you've chosen to share some passwords then I recommended using unique passwords for your most important accounts (banking, medical, email), and only sharing passwords for less important sites. For example, you may choose to have the same password for Facebook and Twitter if it doesn't bother you than an attacker may be able to get into both accounts without additional effort on their part.  You might also share a single password between all news or entertainment sites you visit if you don’t have any financial info tied to them.

What you should avoid is using the same password for an important site (e.g. your bank) and a less important site that may not do a good job protecting your account.  Sites that don’t deal with sensitive info typically have less comprehensive security, which can leave them more susceptible to hacking.  If an attacker steals your password from one of these sites you want to prevent them from getting into your other accounts that do contain sensitive data.

So if you've shared a password between accounts like this you probably should change the password of the more important site to something unique.

Has it been a few years since you've last changed your password?

Finally, after reviewing all these other factors, you can consider how long it has been since you last changed a particular password.  This acts as a catch-all in case you didn't notice suspicious activity, didn't remember sharing a password, didn't know you were infected with a virus, etc.

The only problem with this approach is that we don’t know how often changing a password simply based on its age is actually useful.  We have no idea whether changing a password every 6 months prevents enough hacking to justify that time frame compared to changing it every year.  Our industry has adopted guidelines, mainly for corporate passwords, but these are founded in habit rather than careful scientific reason.

So I won’t pretend that there is a lot of value in setting an arbitrary date on when a password should be changed.  If it makes you feel better to change them every few years, and you don’t mind the work, then go ahead and do it.  If you don’t want to change them regularly, and aren't required to, then I would focus that energy on running through the above questions on a regular basis.  In the long run this latter practice will probably prove to be more valuable to you.

So you've decided to change a password

To make changing your password worthwhile your new one should be something unrelated to the previous password value.  Going from “Muffins14” to “Muffins15” probably won’t protect you from an attacker committed to accessing to your account.

I would also strongly recommend that you take this opportunity to start using a password manager if you aren't already.  Password managers act as a backup to your memory so you feel more comfortable choosing better passwords and changing them as needed.  Some password managers can even supply your password automatically to the sites you log into, removing the burden on your memory entirely.

Here are a few of the more popular password managers:

Free versions:
- PasswordSafe
- KeePass

Paid versions:
- 1Password
- Dashlane
- LastPass


While you are changing your passwords look in your account settings for two-factor authentication (2FA), or any multi-factor authentication (MFA) support on the site that you may not yet be using.  MFA adds another layer of account protection, usually in the form of a one-time code texted to you, a pop-up alert on your phone, or other mechanism designed to supplement the security of passwords.  These mechanisms add another hurdle for attackers to overcome before gaining access to your account, and have the side benefit of rendering regular password changes even less necessary.

More and more sites are starting to support MFA to protect accounts, and I would encourage you to try it out and take advantage of the added security.  

Are Recent Password Guessing Attacks Tied to Devastating Morris Worm?

With recent reports of online password guessing attacks, like those Apple customers may have experienced, is it possible that the Morris worm is responsible?  Yes, I mean the Morris worm from 1988.  The one that impersonated users with weak passwords as part of an attack arsenal that allowed it to spread and overwhelm the then nascent Internet.  Since password guessing was detected shouldn't we assume this worm has resurfaced?

“But Bruce,” you protest, “you're offering no evidence that these things are in any way associated!”  And to you I reply “Well, why should that stop us from speculating?”

Ok, my claim is a bit exaggerated but it was inspired by real news from Namecheap on Monday.  The web hosting company warned customers that they had detected a credential guessing attack, which “likely” matched a recently revealed Russian password collection.  This collection, publicized by security consultant Alex Holden in August, purportedly included 1.2 billion unique credentials stolen by a hacking group nicknamed "CyberVor".  It attracted a lot of attention in the news, along with its own controversy.

So why did Namecheap think the attempted usernames and passwords were associated with CyberVor?  They don't offer a reason in their posted warning.  Furthermore, I don't believe they have a good reason.  The Russian credential cache has not been made public so there are no username or password records for them to compare to the guesses they saw.

My suspicion is that the CyberVor story was still fresh in the mind of someone at Namecheap and they made an assumption that the group's data was involved when faced with their own attack.  Maybe there was also some circumstantial evidence, such as password guesses originating from Russian IP addresses.  Regardless, there's no apparent way for them to know and there's likewise no reason to assume there is a connection.

I can forgive a company for including a seemingly unrelated statement when they aren't accustomed to disclosing details about an attack, but what really bothered me was how a few members of the media failed to question it.

An article by The Register mentioned that the Namecheap news offered "anecdotal evidence" of a CyberVor connection but seems to otherwise present the information as fact.  Infosecurity Magazine's coverage also didn't question how the two events were related, and goes on to wonder if it was the first time the Russian credentials were used in an attack against another site.

I understand that news cycle driven journalism means not being able to fact check every detail being shared, but I feel like the Namecheap claim was important enough to raise a red flag, especially at these two publications.

Meanwhile, IDG News Service did challenge how Namecheap could make this connection and actually took the time to ask Alex Holden (the only person outside of CyberVor known to have a copy of their credential cache) about the claim.  Holden agreed that there wasn't support for thinking CyberVor data was involved.  A SecurityWeek article also questioned whether timing of the two incidents was the only evidence that led to the conclusion, and apparently did try to verify the statement with Namecheap.

In reality, automated password guessing, or brute-forcing, attacks have been a threat long before CyberVor made the news.  The US Department of Defense Password Management Guidelines advised setting minimum password policy standards to combat the threat of login password guessing back in 1985.  Although since the cutting edge technology of that day required passwords to be tried over 1200 baud modems the attacks took a slight bit longer to carry out.

More recently, both web sites and other Internet services have faced increased password guessing attacks.  In 2012 the video game development company ArenaNet (who hosts the Guild Wars 2 MMO) responded to thousands of customer support tickets when criminals successfully guessed player passwords.  Last year, both Konami (PDF) and Nintendo experienced millions of login attempts, taking place over several weeks, aimed at compromising their customer accounts.

One factor these attacks all seemed to share was that the hackers behind them were leveraging usernames and passwords stolen from other hacked sites.  The dangerous and common practice of reusing passwords for different companies can mean that your site is more vulnerable to attack if you have users that also maintain accounts on less secure sites.  If one of those sites is breached and their user database is stolen (possibly with passwords stored in plaintext) it can improve the success that criminals have when attempting to guess credentials on your site.  This likelihood of success probably grows when the hacked site and yours both cater to a similar customer base.

So while it is likely that the credentials tried against Namecheap customer accounts originated from one or more hacked sites, there are plenty of more likely sources for collecting password records other than the CyberVor stash.

On a positive note, Namecheap does deserve praise for having monitoring in place to detect unusual login activity, which allowed them to quickly take steps to protect their customers' accounts.  Instead of the weeks noted above in the Konami and Nintendo cases, Namecheap personnel responded within hours of the attack.  That probably made a big difference in limiting how much damage the attackers were able to do.

Hopefully the company will continue to conduct effective incident monitoring and response just in case the Morris worm does rear its ancient head.

A Review of Real World Security Questions & Answers

Yesterday I delivered my presentation titled A Review of Real World Security Questions and Answers at PasswordsCon 13.  I have written about security questions (AKA challenge questions) before, but this presentation is based on my analysis of thousands of actual user choices that were included in hacker database dumps from three different organizations this past year.

We don't often have an opportunity to see how people are actually using security questions outside of controlled surveys, so I was thrilled to dig into the data to see what additional insights it offered about their strengths and weaknesses.  Hopefully you will find it to be a useful resource when making decisions about the use of security questions in your own organization.

You can find a copy of my presentation slides with my analysis at www.passwordresearch.com/securityqs.html.  If you would like to talk about these findings you are welcome to contact me through email or on Twitter @PwdRsch.  You can also post your comments or questions on this blog entry.

Passwords Found in the Wild for January 2013

Studying the passwords dumped on the Internet by hackers back in December provided a good opportunity for me to measure the scope of the problem. Following that experience I decided to collect and correlate some new information when analyzing password dumps from January.

Overview of Password Dumps

Last month I found 110 password dumps which met my criteria* for analysis, down from 154 in December. A few of the dumps contained data from multiple sites. There were 90 specific organizations or domains named as the source of the passwords. The remaining dumps didn't identify the source of their data, or were gathered from multiple personal computers instead of from a centralized web site.

From this collection, 40 dumps consisted primarily of plaintext passwords, exposing roughly 61,000 passwords (36% of the monthly total). Another 64 dumps primarily contained hashed passwords, adding approximately 101,000 passwords (59% of the total). Six more dumps had a mixture of plaintext and hashed passwords, accounting for 9,000 passwords (5% of the total).

Compared to 450,000 passwords dumped in December, this month's total of 170,000 passwords was significantly lower. A contributing factor to this was the smaller number of dumps, but maybe more importantly there also tended to be fewer large password dumps. This month only had two dumps containing more than 10,000 passwords, while last month had 17.

I wasn't really surprised to see this result. The number of sites that are compromised and the number of passwords they disclose will always change based on what is getting hacked that month and how large the vulnerable sites happen to be.

Over time a baseline average of 150,000 - 300,000 passwords dumped each month might emerge, but this number would skyrocket every time a large site was affected by a security breach. In June of 2012 we watched LinkedIn lose 6.5 million passwords and eHarmony lose around 1.5 million. The next month 450,000 passwords were leaked from Yahoo Voices. Just this past Friday Twitter announced a forced password change for around 250,000 users whose password hashes may have been accessed by hackers (although these have yet to be publicly dumped).

There were 40 different hackers or hacker groups claiming credit for January's password dumps, and more hackers that chose to dump their data anonymously. So even the retirement, capture, or poor motivation of any particular hacker seems unlikely to have a large impact in the flow of monthly password dumps.

The biggest deterrent to future password dumps is more likely to be improvements in the security of the code and development frameworks used by the vulnerable sites, or a widespread adoption of specific security countermeasures (e.g. web application firewalls or intrusion prevention systems). This brings us to the subject of what types of sites I found to be vulnerable today.

Sites Vulnerable to Password Dumps

In January I decided to visit all the sites named in the password dumps and gather information on the software coding language they used, the category of the function they served, and the country in which they were hosted. I hoped this might provide some further insight on whether these attacks were targeted in any way or simply opportunistic.

SQL injection attacks appear to be the primary supplier of the database dumps containing passwords. Many of the dumps include actual output from the tools (like Havij) that hackers can use to automate the extraction of database contents. This seemed pretty intuitive since SQL injection is a common web application vulnerability and one that may not require hackers to gain any other illicit access on the targeted site.

What did surprise me was that the majority of the 87 named sites targeted with password dumps were developed using the PHP programming language, as shown in the following chart.

 

Netcraft's Web Server Survey for this same month shows that 39% of all web sites (around 244 million) are running PHP. While that is a large portion of the Internet, the market share by itself doesn't seem to justify PHP sites making up 91% of the total. After all, sites using ASP and JSP can be just as vulnerable to SQL injection attacks as PHP. If I didn't know that SQL injection was the primary attack method I would suspect that hackers were exploiting some PHP-specific vulnerabilities.

A more likely explanation is that the popularity of the language has led to the rapid deployment of PHP sites and PHP-based content management systems (CMS) by people who lack an education in web application security. Even though the risk of SQL injection in PHP should be fairly well understood, some organizations still end up deploying code that doesn't implement proper security controls.

Interestingly enough, I found that one of the organizations suffering a January password dump had actually showed up previously in a hacker's report of sites vulnerable to SQL injection posted on Pastebin.com over 6 months ago. So either they never learned they were vulnerable in the subsequent months or were unable to completely fix the problem before it was exploited to dump their entire user database.

Another possible explanation is that some of these sites might be unintentionally allowing attackers to connect directly to the site database and download records that way. This should be prevented by host firewall segmentation and proper database authentication, but sites may have been deployed without these precautions. I see evidence within the posted password dump files that this is happening, but I believe it is secondary to the more popular SQL injection attacks.

While all software developers and web admins should learn about SQL Injection prevention and other secure site management practices, it appears that the PHP community needs the most help catching up.

Categories of Targeted Sites

When I visited these vulnerable sites I also assigned them a category based on the site's purpose. Most of these category labels should be self explanatory, but I'll provide a description for a few of them.

Education sites were mainly universities, although there was one primary school. Business sites were a corporate web presence that mainly published data and didn't offer online services to customers. Entertainment sites could be a discussion forum or a site sharing information on a specific topic (e.g. movies or sports).

An Online Store was a business site where customers could make purchases. This type of site would be particularly valuable to attackers looking to capture stored billing information or to order merchandise and charge it to customers. As mentioned last month, sites like this often don't make it into public password dumps because attackers can sell the account data in the underground marketplace.

Info Services are the sites that sell information as a single-use or subscription service. These sites could also be valuable to attackers, depending on what type of data they make available to customers. Finance sites are banks, credit unions, or other related institutions, but in this month's case it was a single investment firm.

The chart below shows how many sites matched each category in the January password dumps.

I didn't really have many preconceived ideas about the categories of sites I expected to see targeted. Government, Business, Medical, Education, News, and Political certainly make sense if the attacker hopes to gain media attention with their data dump. 

The Online Stores, Info Services, and Financial sites make sense if the attacker hoped to make a financial gain from the attack. Although going after these sites could also certainly just be for bragging rights.

There is probably some ratio of opportunistic and targeted attacks in this mix, but it is difficult to detect unless the hackers specifically outline their motivations in the dump descriptions.

Countries Hosting the Targeted Sites

I was able to identify the country of origin for 96 of the January password dumps. There were 35 different countries represented in that total. The top 10 countries that experienced the most password dumps are shown in the chart below.

Seven other countries tied the Philippines with two vulnerable sites each. South Africa was given a bit more attention in January than normal due to one hacker group specifically targeting organizations in that country as part of a political statement.

Another observation was that half of the vulnerable sites in India were Education category sites. They were the only country that had such a large percentage of their sites in the same category. This might indicate greater web site security problems at universities in India, or it could just be chance.

Impacts on Users of Targeted Sites

At least some users of the hacked sites are likely to experience problems as a result of these password dumps. If passwords were stored in a plaintext format then any account is vulnerable to misuse by unauthorized individuals. Even if hashed, password cracking software can produce the plaintext passwords fairly quickly for all but the stronger passwords. Whether hackers care to use these stolen credentials will depend partially on what the account can be used for and partially on how motivated they are to annoy users.

Some web sites use an email address for the username, or record the email address during the account registration process. Email addresses of users were found in 96 (87%) of the analyzed password dumps in January.

The use of email addresses isn't necessarily a problem by itself, but the reality of user password practices can result in email address leaks endangering their identities on other Internet sites. If one organization leaks email addresses and passwords this allows attackers to try those credentials elsewhere. In fact, hackers have developed software tools that automate the process of trying discovered email and password combinations against a list of popular web sites.

Password reuse makes this a real problem, although mainly for the users and not necessarily for the site that was vulnerable to the password dump in the first place. Even if a user chose a stronger password to reuse, it only takes one site storing that password in plaintext to potentially expose all of their accounts.

My suggestion to users is that passwords should never be reused across any sites where you would care if your account gets hacked. Always choose a strong and unique password for each site and then store it in a password manager if you are concerned about forgetting it.

Web sites often can't do much to prevent password reuse other than enforcing good password selection controls that might eliminate the worst of the reused passwords. However, they can make sure that they use adequate password hashing and salting techniques that make the task of cracking user passwords much more difficult for hackers. Sites should also notify users when a database breach is detected and warn them to change their password anywhere else it was used, in addition to forcing a change on the hacked site itself.

Conclusion

I wasn't able to complete my analysis of all the information provided by the password dumps in January, but I'll continue to work on it and will post new results here on the blog. In the meantime, if you have any questions or comments leave them below, or contact me on Twitter @PwdRsch.

* Study Methodology

I monitored Twitter and other sites for notices that a data dump had been publicly posted. Some data dumps contained user or customer information but not passwords. Others contained only the administrator password or the passwords of a very limited number of users. I ignored these and focused only on sources that contained passwords (hashed or plaintext) of at least a dozen or more users.

I also attempted to eliminate duplicate dumps, a practice where one hacker copies a full or partial dump from someone else and reposts it as their own. Sometimes these dumps are from the same month and sometimes they are from previous months.

In a few cases the dump poster noted that they had included only a subset of the available user passwords. While I didn't count the unposted passwords, we should assume that the attacker had access to the complete user database, which would increase the total number of passwords exposed.

When reviewing these figures keep in mind that they account only for the publicly posted data which I was able to discover. Hackers certainly compromised the passwords of other sites and kept this activity secret, or shared the data over more private channels.

Passwords Found in the Wild for December 2012

In the late 1990's when I started analyzing passwords it was much harder to find samples to review.  My password collection routine consisted mainly of begging colleagues to share data or volunteering to perform the cracking for their security assessments.  Occasionally I would get lucky and find a publicly readable password file on the Internet.  Then I could dedicate a computer for several months to cracking each password database because it would certainly take at least that long before another sample showed up.

Today I find that I am actually overwhelmed with the opportunities to gather passwords.  The raw number of Internet sites that register users and collect their passwords is huge.  Correspondingly, the number of these sites that are susceptible to SQL injection or other vulnerabilities that allow attackers to extract their user databases has also grown.  Hackers are regularly exploiting these flaws and publishing password dumps to embarrass companies, to attract attention to their causes, or to simply stroke their egos.

I decided to monitor password dumps in December 2012 to get a better idea of how widespread this practice has become.  I monitored several sources (though mainly the Pastebin.com web site) for announcements of dumps and analyzed the data posted.

Study Methodology

Snippet of Password Dump Tracking Data

Some data dumps contained user or customer information but not passwords. Others contained only the administrator password or the passwords of a very limited number of users.  I ignored these and focused only on sources that contained passwords (hashed or plaintext) of at least a dozen or more users.  I also attempted to eliminate duplicate dumps, a practice where one hacker copies a full or partial dump from someone else and reposts it as their own.

In some cases the dump poster also noted that they included only a subset of the available user passwords.  However, we should assume that the attacker had access to the complete user database, which would increase the actual number of passwords exposed.

When reviewing these figures keep in mind that they account only for the publicly posted data of which I was made aware.  Hackers certainly compromised the passwords of other sites and kept this activity secret, or shared the data over more private channels.  Brian Krebs covered the underground marketplace for the more valuable passwords in his recent blog post.

Password Dump Findings

In December I found 154 dumps which met my criteria for analysis.  A few of the dumps contained data from multiple sites.  They named more than 125 different organizations and domains as the source of the leaks.  Passwords belonged to users at businesses, governments, schools, industry groups, and discussion forums.  Some dumps didn't identify the source of their data, or were gathered from multiple personal computers instead of from a centralized web site.

From this collection, 66 dumps consisted primarily of plaintext passwords, exposing roughly 221,000 passwords.   Another 82 dumps primarily contained hashed passwords, adding approximately 222,000 passwords to the count. So while the number of hashed password dumps was greater than the plaintext dumps, the number of passwords exposed was nearly equal.  Six more dumps had a mixture of plaintext and hashed passwords, but only accounted for 6,000 passwords.

Altogether, I found that almost 450,000 passwords were publicly exposed during the month. There were 103 dumps containing less than 1,000 passwords, and 17 dumps containing more than 10,000 passwords.  About 184,000 passwords (41% of the total) came from several dumps simultaneously released as part of Team GhostShell's Project WhiteFox on December 10th.

Finding that half of the exposed passwords lack the security provided by basic password hashing is disappointing.  While some of the affected sites likely have low security requirements, storing only password hashes is a pretty standard security practice that should be followed by almost every site.

Without password hashing both the poorly and well constructed passwords are exposed during leaks like these.  A user may think their password is secure only to find that their account has been compromised due to insecure password storage that was beyond their control.

Even hashed passwords can only offer resistance against attacks once they have been stolen from an organization.  Password crackers have become faster and more proficient at trying common words, names, phrases, and other combinations of guesses that can disclose a password after it has been hashed.

Conclusion

My feelings are mixed when it comes to the results of this study.  On one hand I'm frustrated with the security vulnerabilities that continue to plague many Internet sites, and on the other hand I'm eager to see what wisdom is provided by examining these leaked passwords.  The wide variety of passwords from these different sources allows researchers like me to pick and choose the password samples that seem most interesting or likely to produce the information we seek.

So these days instead of begging for passwords I'm finding myself begging for help to sort through all the password data that is available to me.

Finding the humor in changing your password

On the lighter side of things, here's a reminder of what users may experience when it comes to changing their passwords:
http://www.washingtonpost.com/wp-dyn/content/article/2009/07/12/AR2009071202012.html?hpid=sec-metro

Embassy password hacker reveals his technique

A Swedish hacker calling himself "DEranged" attracted media attention over the past couple weeks by posting a list of 100 government email usernames and passwords. His list included email accounts used by embassy officials from India, Russia, Iran, Hong Kong, and others. A few journalists verified that these credentials could indeed be used to access private email.

At the time of his original disclosure DEranged (his real name is Dan Egerstad) withheld details on how he came into possession of the passwords, instead writing that "there is no exploit to publish, no vendor to contact". Today he posted an entry on his blog describing how he used newer software to exploit an older problem.

Egerstad established several computers as nodes in the Tor network. As a part of this network, these computers would act as intermediary routers in the delivery of Internet traffic. By routing this traffic Egerstad also gained the capacity to capture and analyze any unencrypted packets sent through his systems. He then used this access to collect thousands of usernames and passwords transmitted to email servers in the clear.

I will not praise Egerstad due to his poor ethics in disclosing passwords in the manner that he did, but ultimately he is right in pointing out the serious shortcomings of protocols that still transmit unencrypted passwords.

There have been secure alternatives to POP3, such as POP3 over SSL, for some time. However, many companies and service providers fail to offer them, let alone make them the default setting. Organizations can only justify this continued practice because of the difficulty in detecting password capturing attacks. IT personnel can avoid responsibility by dismissing password thefts as a user problem resulting from phishing attacks or software trojans. This is an unacceptable response.

With the growing number of mobile users and wireless networks, the opportunities for password capture attacks will increase. If you are using POP3, Telnet, HTTP, FTP, or any other unencrypted protocol for transmitting passwords, look into alternatives today. People with more dangerous agendas than Egerstad will be watching to see if you do.

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.

We know about password attacks in Kansas

I was making a dent in a sink full of dishes tonight and half listening to the TV when a show caught my interest. Dateline NBC was airing a segment on the disappearance of John Elwin during a business trip. Apparently his girlfriend, Kirsten Flood, wasn't initially having luck interesting authorities in a search for clues about the whereabouts of Mr. Elwin. Frustrated, she engaged a friend, Denise Tripoli, with "experience in Internet security" to help.

The following excerpt comes from the show's transcript:

   If only she could hack into Elwin's e-mail account, they might discover where he was.

   The two women wracked their brains trying to guess at a pass code that would give them access.

   FLOOD: [We tried] his birthday, his social security number. And I just kept going down the list until I hit it.

   FLOOD: And lo and behold, we got into it.

   BOB MORRISON: What did you find there?

   TRIPOLI: We broke into his account at eleven o'clock at night, and I was up till three in the morning, looking through every e-mail. And I was very disturbed by what I saw.

I certainly won't pretend that I would avoid this temptation if one of my friends or family members went missing and I had exhausted other options. Nonetheless, I was a little disturbed by the casual explanation of how these women broke the law to gain access to Mr. Elwin's email account. In my opinion, reporting this part of the story in this manner trivializes the ethical and legal implications of getting into another person's email account.

You would expect that a news organization so eager to expose the secret underworld of hackers would act more responsibly.