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.

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.

Circumventing password reset systems

A hacker who goes by the alias “pdp” recently posted information about Attacking Password Recovery Facilities on his blog. He reviews several approaches to gaining unauthorized access to user accounts by circumventing security in the password recovery function of a system rather than trying to guess a user’s password.

Since attackers will often follow the path of least resistance in penetrating a host, it is incredibly important to make sure that password recovery functionality is designed to resist attacks.

I described one of the attacks, determining the answers to a user’s challenge questions, in the white paper I mentioned in a past blog entry. Hopefully his post will help to convince more people that attackers are going to be a real threat to their challenge question authentication systems, whether used for password recovery or secondary authentication.