Hi. I'm customer outside of US and I received the email, went to site to reset my password and "We are so sorry – we are currently not accepting international traffic" - WTF? (sorry, but there is your logic?)
Just a precaution while we asses and deal with this. Zappos doesn't ship internationally so we hope this isn't affecting many customers. But to those that are, we apologize. As soon as we can we'll re-enable traffic from outside the US.
I for one would love Zappos to ship internationally, and your owners at Amazon already do. I know you can't comment, but please do what you can to push for selling to the other 6.7 billion of us.
I'm in Chile as part of Start-Up Chile. What exactly do you need? PS - I am also a US customer. A block on international traffic effects more than just international customers.
Ah, I understand now. You mean you want companies to just replicate Zappos outside the US. Any chance that there could be a "Zappos API" where we could while label Zappos, and pick-up the goods at the Zappos warehouse for foreign shipment?
I think they developed Javari in most of their European markets and logistics are handled by Amazon themselves.
Zappos is operated completely separately from Amazon so in order to expand internationally they would have to roll their own operations internationnaly.
As a developer who fears these kinds of attacks on my own sites, is there anything you are able/allowed to reveal regarding how the attack happened, how it was discovered, and/or how it could be prevented?
Good job on not storing or sending clear text passwords. However, as others have indicated, we would like to know more about the hashing method used.
As a side note, I was horrified to discover that Hertz sends passwords (as part of password recovery) in the clear. For those using Hertz, you should take the appropriate precautions.
+1 for bcrypt - "ordinary" hashing algorithms were made to compute as fast as they can, which is exactly the opposite of what you will want for your system. Rainbow tables are so quick and easy to make - IIRC it currently takes only some hours to compute all MD5 hashes for passwords up to 8 characters long on a system with some good graphic cards.
What you want is an algorithm which takes an up-to-date system some 10-100ms to compute a hash - bcrypt is configurable in its complexity (time to compute hash), and you should adapt the parameters every 1-2 years to increase the complexity.
Security through obscurity should not used. Just saying. IMO, revealing the method used should not become an issue just like the reason why the more trusted crypto algorithms are publicly posted.
That said, bcrypt and a time/attempt limited lockout should go a good ways in securing your site.
Salt. Seriously. A big, long, gnarly-looking salt. Preferably a unique salt per user. Really, even just that is sufficient, even if stored right next to the hash. It means doing a bruteforce/dictionary attack one user at a time rather than one bruteforce/dictionary attack of all the users at once (static salt) or just googling the hash (unsalted hash).
Also, are these passwords encrypted or hashed? Those two are miles away from each other and you guys are using both words nearly interchangeably. If encrypted, where is the key? Was it compromised?
MD* - No, SHA* - No, Bcrypt - Yes!, Scrypt - Not yet (PDI). Make sure you also calibrate the work factor for Bcrypt, too. Then, write a blog entry about your findings.
Plaintext passwords never touch our database. Expiring everyone's passwords was a security precaution given the fact that our non financial customer data was compromised in the first place. I can't comment on what lib or algorithm we use to encrypt our passwords since I don't work on that team.
Obviously in this kind of situation we (Zappos customers like myself) need to change any re-used passwords since the stolen unsalted hashes :( can be cracked. However, I have no idea which of several passwords I used at Zappos! I would normally just try logging in with each of them, but since you've reset all passwords, it looks like I won't be able to. Is there any chance of helping with this? I need to make sure it wasn't a password I use on any important sites (or derived from such a password).
I'm looking for the data dump right now, in case it was posted publicly--that's probably the only way I'll be able to answer my question since I doubt Zappos will cooperate :(
As someone who was just bit by the Stratfor data loss, this is the second month in a row. Fortunately my Stratfor password was worthless, but I had my credit card stolen and used to pay for video games. And now my email and street address are public information.
Most likely your password reset email is in the queue to go out. Emails are slow to go out due to the massive volume of outgoing email we are trying to send out.
"dear bestnameever, i know about those high heels you bought, and i happen to know you don't have a girlfriend. $1000 in unmarked bills or we tell your father you're a cross-dresser."
Or the incredibly geeky wife who suspects her husband is showering the hot secretary with shoes and handbags, and confirms it by poring over the breached data.
All Zappos customers will be receiving the email linked to in this thread. If you haven't it might be in your spam folder or it might still be queued to go out. The link above is the same as the email contents.
I apologize if my question was unclear; that's almost certainly because of a lack of expertise on my side.
On one end of the spectrum, I envision the same salt used for every user, allowing for the easy and effective creation of rainbow tables. On the other end, I envision unique salts with many bits of entropy for each user, making rainbow tables technologically infeasible.
