Zappos Hacked: Internal Systems Breached

wiredmikey writes "Zappos appears to be the latest victim of a cyber attack resulting in a data breach. In an email to Zappos employees on Sunday, CEO Tony Hsieh asked employees to set aside 20 minutes of their time to read about the breach and what communications would be sent to its over 24 million customers. While Hsieh said that credit card data was not compromised, he did say that 'one or more' of the following pieces of personal information has been accessed by the attacker(s): customer names, e-mail addresses, billing and shipping addresses, phone numbers, the last four digits of credit card numbers. User passwords were 'cryptographically scrambled,' he said."

Comments

breach database?

[GuldKalle]

Is there a site covering breaches like these? It would be nice to have an easily searched database with number of users, the kind of info that was accessed, the attack vector etc.

Re:breach database?

[Securityemo]

http://datalossdb.org/

Re:breach database?

[bondsbw]

I'm not sure what you're looking at. Its latest report is January 13, 2012.

http://datalossdb.org/index/latest

True, it doesn't mention Zappos yet.

Cyber attack?

[Anonymous Coward]

I hope the cyber police do what they can to find the cyber criminals who committed this cyber crime against Cyber Zappos. After all, Cyber CEO Tony Hsie- oh fuck I can't keep this up.

Don't call it a cyber attack. It was an attack. This isn't 1996.

Re:Cyber attack?

[mixmasta]

Then the hackers drove away on the INFORMATION SUPERHIGHWAY ... in a YUGO, oops... equivalent of a CYBER-CORVETTE.

First the bad news..

[lemur3]

from the email going out to customers:
Subject: Information on the Zappos.com site - please create a new password

First, the bad news:

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 (but not your actual password).

THE BETTER NEWS:

The database that stores your critical credit card and other payment data was NOT affected or accessed. ...translation:

The Bad News is that things are shitty.

The Good News is that people are learning to love the smell of shit.

Storing passwords (not as easy as you think)

[seifried]

Sadly password storage is actually tricky and most places do it wrong (using MD5/SHA1 for example). Covered in Nov 2011 article Storing your passwords properly (disclaimer: I wrote it, and it's a PDF file). One problem is that even if zappos enforces strong passwords users have a tendency to reuse their strong passwords between sites (you can only memorize so much gibberish or passphrases). Hopefully Zappos learns from this and builds a more resilient system.

Re:Storing passwords (not as easy as you think)

[dgatwood]

Like storing authentication information on a separate server from user information. This tends to make the info a lot less useful.

Ooh. User ID #67215298's password is "correct horse battery staple". Who is user ID #67215298? Uh... we haven't cracked that server yet.

Re:Storing passwords (not as easy as you think)

[seifried]

I assume you mean http://www.tarsnap.com/scrypt.html and https://github.com/pbhogan/scrypt? Looks interesting, I'll have to check them out.

Re:Storing passwords (not as easy as you think)

[Cato]

Mod parent up, the article is quite good.

A more general and simpler answer though is to *always use a standard library* - see http://stackoverflow.com/questions/1581610/how-can-i-store-my-users-passwords-safely/1581919#1581919 for a good answer.

Also ensure that your password storage is one-way hashed, and *salted* with a random salt (different per user) and uses *password stretching* (i.e. iterates the hashing function thousands of time to make brute forcing much more expensive). See http://slashdot.org/comments.pl?sid=1987632&cid=35150388 for more on password stretching including phpass, the gold-standard library for PHP used by WordPress, Drupal, etc.

Most importantly, never write your own password storage - you are virtually guaranteed to get it wrong. Apart from the above issues, what about timing attacks (Zend has an article about this from PHP perspective.)

Re:Storing passwords (not as easy as you think)

[Anonymous Coward]

I'm going to have to disagree with this statement from your article: "Because hash functions like AES-256 only provide 2^256 possible unique outputs, collisions are obviously possible".

Re:Storing passwords (not as easy as you think)

[Anonymous Coward]

You know, I almost posted something when this article was first published but I decided it wasn't worth it. But now that it's come up again in the context of helping people I must say something.

This article is absolutely full of errors.

The end recommendation of using bcrypt is fine, but beyond the basic concepts the rest has major problems. A few examples:

1. AES is not a hash function. It can be used in some constructions to emulate a hash, but you wouldn't just call that AES-256 as you do, nor is it commonly used this way.
2. "Because hash functions like AES256 only provide 2^256 possible unique outputs..." Only? This would put you at ~2^128 outputs before you could really hope to get a collision (and not a collision with a specific output, just any two outputs colliding). This is WAAAY beyond the resources of all of humanity.
3. "Brute-forcing older algorithms is definitely possible now (DES and 3DES already fell to brute-force attacks several years ago)." Since when was 3DES brute-forced? I see no evidence that even 2TDEA has been brute-forced, let alone 3TDEA which is what people actually use. Citation greatly needed.

There are other problems a well, but these are enough to give a taste of the issues.

Re:Storing passwords (not as easy as you think)

[fatphil]

It's hard to take seriously an article which contains remarks like the dumb:
"26 letters, 10 numbers, 11 other character keys for a total of 94 characters"
to the misleading:
"Because hash functions like AES-256 only provide 2^256 possible unique outputs, collisions are obviously possible".

It also overlooks the fact that you're increasing your workload by a factor of X in order to increase the attacker's workload by a factor of X. Therefore there is precisely no leverage at all, and it's not really much of a win, that's a break even cost-wise.

The paragraph beginning "The advantage of bcrypt..." also seems to show that you don't appreciate the difference between a PRP like AES and a PRF like MD5 when it comes to collisions from iterated images. I'm not 100% sure about the logic you're using to lead to the "1000 possible values" claim either. If fact quite the opposite. Are you claiming that if MD5 were iteratd 2^160 times, there would be 2^160 such possible values? (I.e. every input would match a password stored in the rainbow tables.) Sounds bogus, in fact.

Yes

[happyhamster]

6 pm appears to be a "value" branch of zappos: http://blogs.zappos.com/blogs/ceo-and-coo-blog/2008/02/19/zapposcom-and-6pmcom

Kudos to Zappos for the way they handled this.

[I'm Not There (1956)]

Shit happens, the way handle crisis is what matters. Zappos was very open about this, sent me an email, asked me to change password, set up new email addresses and web pages for this problem and questions that customers may have, and announced the issue quickly.

I wish more companies would act like this.