From the consent agreement, in addition to a bunch of fuzzier stuff about standing up a security program, the FTC has demanded:
1. Technical measures to monitor all of Respondent’s networks and all systems and
assets within those networks to identify data security events, including unauthorized
attempts to exfiltrate Personal Information from those networks;
2. Policies and procedures to ensure that all code for web applications is reviewed for
the existence of common vulnerabilities;
3. Policies and procedures to minimize data collection, storage, and retention, including
data deletion or retention policies and procedures;
4. Encryption of all Social Security numbers on Respondent’s computer networks;
5. Data access controls for all databases storing Personal Information, including by, at a
minimum, (a) restricting inbound connections to approved IP addresses, (b) requiring
authentication to access them, and (c) limiting employee access to what is needed to
perform that employee’s job function;
6. Policies and procedures to ensure that all devices on Respondent’s network with
access to Personal Information are securely installed and inventoried at least once
every twelve (12) months, including policies and procedures to timely remediate
critical and high-risk security vulnerabilities and apply up-to-date security patches;
7. Replacing authentication measures based on the use of security questions and answers
to access accounts with multi-factor authentication methods that use a secure
authentication protocol, such as cryptographic software or devices, mobile
authenticator applications, or allowing the use of security keys; and
8. Training of all of Respondent’s employees, at least once every twelve (12) months,
on how to safeguard Personal Information;
#7 jumps out at me. The problem CafePress has is that they used security questions rather than the industry-standard practice of just sending password-reset emails, which meant the answers to those security questions were password-equivalent, and, of course, stolen in the SQLI attacks. But the simpler fix here is just to require password reset emails, not to mandate multi-factor authentication. Though I wonder if they'll just claim email resets are a second factor.
#1 sounds like a boondoggle for security companies, selling software that doesn't actually do much; but perhaps I'm out of the market too long to know what's the current standard.
I for one don't like how companies use email as a security crutch.
Ownership of an address at a particular point in time doesn't equate to proof of identity. One hacked email account and everything else falls like dominos.
I’d much rather have the option to disable password recovery processes. Don’t force me to answer questions with obvious answers. Don’t send a reset link over a possibly insecure channel. Give me a way to turn all of that off and let me be responsible for keeping my password.
> But the simpler fix here is just to require password reset emails, not to mandate multi-factor authentication.
Password resets lead to iterative passwords, which lead to password reuse, which lead to email compromise, which leads to it being pointless to use email as some ersatz second factor.
If we want to move towards a world where phishing attacks and password breaches are obsolete, then we need to press full-throttle to mandating hardware security keys for all accounts.
It is very much the FTC's place to require companies to live up to the commitments they've made to customers, and probably, more broadly, to make sure they live up to the implied commitments of universal industry best practices. It is less clear that FTC has the authority to turn random companies into test cases for the elimination of phishing attacks.
The practices CafePress had prior to its breach were clearly inadequate, and justifiably actionable. They authenticated users with password-equivalent "security questions", which they (of course) stored in clear text. Storing cleartext password reset secrets contravenes universal industry best practices, and, really, so does the use of "security questions" at all --- though many banks still do.
But requiring 2FA tokens is not a universal practice. Moreover, deployed over a whole userbase, it doesn't really address the concerns that lead to or were revealed by this breach. Managing 2FA for non-technical end users --- that's the kind CafePress serves --- is extraordinarily difficult. People lose tokens, 2FA codes are phishable, account recovery remains the most difficult problem in computer security, and so on.
So yes, it is weird to me to see the FTC suggest that the appropriate solution to a broken authentication system with security question is "make people use 2FA tokens". The universal best practice solution to the specific problem the security tokens solved is "password reset emails that prove custody of a trusted email account". The demand from the FTC exceeds that best practice. That's interesting, and so I called it out.
We don't know each other, so it probably bears saying that I am foursquare supportive of 2FA. I'm supportive of a lot of things the FTC would no doubt love to force companies to do (penetration testing in particular!)
> But requiring 2FA tokens is not a universal practice.
It is not universal practice, but it is industry-standard, so I don't particularly understand why it is surprising that the FTC is recommending that CafePress adhere to industry standards.
2FA is not in fact the industry standard process for account recovery (it's the industry standard problem that causes us to have to spend time on account recovery!), and account recovery is the problem this part of the consent agreement addresses.
> To maintain the integrity of the authentication factors, it is essential that it not be possible to leverage an authentication involving one factor to obtain an authenticator of a different factor. For example, a memorized secret must not be usable to obtain a new list of look-up secrets.
And further:
> Methods that do not prove possession of a specific device, such as voice-over-IP (VOIP) or email, SHALL NOT be used for out-of-band authentication.
That's the NIST standard definition for out-of-band authenticators. FTC didn't demand out-of-band authenticators, nor is anyone obligated to comply with NIST.
Yes. For obvious reasons, people are more prone to lose 2FA authenticators (be they code generators or hardware keys) than passwords. Both passwords and 2FA mechanisms are customers of account recovery, which is the process that kicks in when you can't log in. Security questions are a particularly bad account recovery system. Reset emails are somewhat better.
Again, 2FA isn't an account recovery process at all; it's a reason you need account recovery.
To get a general sense of where we're at as an industry with this, look at the process for what happens when you lose an AWS 2FA secret:
> Again, 2FA isn't an account recovery process at all; it's a reason you need account recovery.
Your reading of the FTC text seems to be that you think the FTC has conflated account recovery with 2FA, but I don't think that's the case. Instead, my read is that they're suggesting that password breaches can be rendered moot points by requiring 2FA for accounts, so that the compromise of a password would not require an account reset in the first place.
I'm reading the plain language of the agreement, which requires the replacement of security questions and answers, and is not in fact a manifesto about the insecurity of passwords writ large.
But technical language aside: a requirement that CafePress fully adopt 2FA also doesn't make sense, because its users will not fully adopt 2FA. The users that can't 2FA are the interesting case here, and the thing I'm calling out.
I think you think they mean password expiration, not password resets. I don't see how the existence of a "I forgot my password" (password reset) flow leads to reused passwords, though automatically expiring passwords certainly do
