Zappos Hacked: Internal Systems Breached 122
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."
Re:breach database? (Score:4, Informative)
Storing passwords (not as easy as you think) (Score:5, Informative)
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 [linux-magazine.com] (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.
Yes (Score:4, Informative)
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 [zappos.com]
Re:Storing passwords (not as easy as you think) (Score:5, Informative)
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) (Score:5, Informative)
"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.
Re:breach database? (Score:5, Informative)
I'm not sure what you're looking at. Its latest report is January 13, 2012.
http://datalossdb.org/index/latest [datalossdb.org]
True, it doesn't mention Zappos yet.