The Zappos Breach and Textual Password Based Authentication

Following their major database breach, Zappos leadership is doing the right thing by what seems to be quickly and clearly communicating what data was accessed and what was not – there are no unexplained delays or confusion on their part about the event. It’s like another Aurora moment in my book, when Google extraordinarily opened up about their breach while the other 30-odd Aurora-breached major corporations did the opposite, aggressively maintaining NDA’s to hide their Aurora incidents and hide their heads in the sand. Zappos reset 24 million customers’ passwords and emailed all of them about the problem last night.

Zappos also sent all 24 million users a concise email explaining “We are writing to let you know that there may have been illegal and unauthorized access to some of your customer account information on Zappos.com, including one or more of the following: your name, e-mail address, billing and shipping addresses, phone number, the last four digits of your credit card number (the standard information you find on receipts), and/or your cryptographically scrambled password,” while “THE DATABASE THAT STORES OUR CUSTOMERS’ CRITICAL CREDIT CARD AND OTHER PAYMENT DATA WAS NOT AFFECTED OR ACCESSED.” All of this has been discussed and should be standard, timely stuff for notifications. But there remain a couple interesting points.

1. Zappos should maintain stronger password policies

2. Zappos could still clarify details about the breach, exactly what was in the database and what the heck they mean by “cryptographically scrambled passwords”.

Everyone has their own thoughts on password policies and tradeoffs. My own simply put – I am a fan of long passwords, I am a bit of a fan of OpenID for accounts that are not sensitive (is it that damaging if most folks’ comments at their local newspaper account or even more major forums are temporarily hijacked?) and maintaining varying levels of sensitivity per account type, and I am a fan of password vaults to help maintain the growing piles of accounts and passwords.

Have website operators learned lessons from previous incidents about maintaining the strength of passwords for customers’ “post-breach”? Keeping in mind that Zappos is a retail site involving financial transactions, any related user authentication data is sensitive. Zappos most likely maintained a cryptographic hash of their customers’ passwords along with an unique per-user salt value in this breached database. But they need to explain whether or not this scheme is what they meant by “cyptographically scrambled”. “Scrambled” is not common security jargon and most likely tossed out by a marketing writer doing their best with the situation. Are they maintaining salted md5’s for their password values? How about something stronger and why not? These breaches happened all through 2011, often for the “lulz”, most site operators should be planning for the worst. Also, Zappos will not allow users to use any of the last six passwords. Does the company really need to store their users’ previous six passwords? Were all of these passwords stolen as well, there is no indication in the email?

When the Zappos team forced their users to reset their passwords last night, they enabled their users to provide a minimum of 8 character passwords, including 1 upper and lowercase letter and 1 number or 1 special character. So users’ pass could look like “Zappos12”, and here lies a bigger problem. With “rainbow tables” that have been circulating as a part of both commercial products and open source projects discussed at major security conferences for years, this weak password scheme could be quickly cracked offline. It is no longer reasonable to simply say “use a mix of 8 values” and call it a day. Mark Burnett’s 2006 writeup on “Perfect Passwords” describes the password cracker/defender number game very well in what are becoming outdated terms already, and presentations last year at Defcon 19 demonstrated the economics and capabilities of contemporary cracking, particularly in the GPU era. Powerful, dirt cheap GPGPU hardware and current cloud solutions can crush unbelievable levels and volumes of password unpredictability and uniqueness in very short time frames. Eight characters simply don’t cut it.

Finally, not only do we need stronger but more practical password policies than what are being pushed by major site operators, but we need to think more than a few years out about the failing authentication schemes that badly need to be fixed, including ubiquitous simple text password use.