Software Integrity

 

Kickstarter password Breach … #FTW?

Last Wednesday I spoke about password storage security in a WhiteBoard session. Fate has allowed a publicized password breach within a few days prior to these talks nearly without fail and, with the hack of Yahoo’s 3rd party database more than a week in the rear-view, I was a bit self-conscious. Cue the Kickstarter security notice.

Let’s eschew admonishing Kickstarter and look at what their disclosure shows about what went right (*1)(*2):

I first became aware of the issue when I received an email from Kickstarter. It read:

As a precaution, we have reset your Facebook login credentials to secure your account. No further action is necessary on your part.

Awesome. Users don’t want their credentialing material stolen from a system they use, but if it happens, this is a pretty good result:

  1. The organization announced the breach;
  2. The system’s administrators revoked the stolen token’s access; rights
  3. No action, on the user’s part, is necessary.

Compare this to what other users saw:

As a precaution, we strongly recommend that you change the password of your Kickstarter account, and other accounts where you use this password.

Classic. Editorializing: “We lost your password, albeit protected. From this, a motivated attacker can acquire your password and gain access to other systems in which you also use these credentials… …especially with your [weak] password.”

Passwords? What passwords?

The first message, the one I received, is a very concrete (and personal) example of the advantages of allowing users to opt-in to a more modern authentication workflow rather than continuing to rely solely on username/password. Kickstarter, for their part, relied on Facebook Login. So, from the beginning, Kickstarter didn’t have to store my password and therefore could not lose said password in a breach (*3).
I’ve been misquoted as saying “Using passwords to protect your account will help you as much as motorcycle helmets will protect you at high speed.” By now it should be clear: relying on passwords as the sole/principal authentication mechanism is foolhardy. We can and must do better:

  1. Schemes like OAuth prevent theft of plain-text credentials, such as passwords, from server-side storage;
  2. Multi-factor authentication provides defense-in-depth and prevents unauthorized account login using theft of [only] plain-text credentials.

For years now, we’ve seen organizations use the above to improve security in and around authentication and related workflows. Larger organizations, particularly as a result of opportunities on mobile platforms, have begun to think about how to gain an understanding of and use end-user behaviors to to augment authentication workflows.

Rebuilding the Plane in the Air

Still, some users did see the scary “reset your password on any sites that shared these stolen credentials” message. The reality is this: many sites will continue to support the option of simply databasing UN/PWs because this, frankly, is the default behavior and implementation of popular web frameworks. Here too, the Kickstarter release provides a ray of hope:

How were passwords encrypted?

Older passwords were uniquely salted and digested with SHA-1 multiple times. More recent passwords are [sic] hashed with bcrypt.

Yes, I twitched the first time I read this. SHA-1 “multiple times”!? But, reading into this answer a bit more, we may deduce developers:

  • …at least salted passwords; (*DS)
  • Knew enough to add work to password hashing by iterating… even if they did ‘roll their own’ (*4) SHA-based scheme;
  • Were moving to a cryptographically strong, adaptive one-way scheme;
  • Built a system that could handle in-place upgrades to their PW scheme, while supporting inactive users.

Looking at the above, the system–while quite imperfect–had a lot going for it. In particular, it was moving to increasingly secure storage over time. I wish I could say as much for the average system we assess. Indeed, seldom do we come across the last bulleted capability (in-place upgrade) in systems we assess.

For more on protecting stored passwords securely, look at the OWASP Secure Password Storage Cheat Sheet I helped author.

Looking Forward

Though I joke that “Every time I give a password storage security talk there’s been a breach”, it’s not really that inaccurate. Authentication based solely on passwords is simply not good design. Storing passwords securely will remain thorny–each scheme trades good features for bad consequences (if you’d like more gory detail, find it within my Secure Password Storage Threat Model).

But, if we have to look forward to a continued deluge of password breaches, I’d like them to start looking more like this Kickstarter event and less like the Yahoo! and LinkedIn events that spawned so much misinformation I begrudgingly begun writing on the topic. With any luck, I’ll be posting links to my [yet unpublished] OAuth and MFA-based authentication threat model instead.

-jOHN

* (1) – Breaches are bad–sure. Some vulnerability in people/process/tech allowed this to happen. OK. Is Kickstarter handling it correctly? Will this hurt them? ‘Not interested in those questions’ answers here.

* (2) – DISCLAIMER – I have no proprietary knowledge of Kickstarter’s authentication or password verification/storage design. This entry’s commentary is drawn only from the organization’s release information, which is taken at face value.

* (3) – Three-legged authentication undertaken as implied here presents more complexity than a simple UN/PW check. Developers without an understanding of the OAuth protocol may find required extra steps confusing. Sensitive tokens, other materials, and connections handled throughout this workflow offer developers new opportunities to introduce vulnerability and/or expose access to the system. Nothing in life is free… …not even Facebook 😉

* (DS) – My wife would be proud.

* (4) – Do *NOT* roll your own scheme.