13,000 Passwords, Usernames Leaked For Major Commerce, Porn Sites
The Daily Dot reports that yesterday a "group claiming affiliation with the loose hacker collective Anonymous released a document containing approximately 13,000 username-and-password combinations along with credit card numbers and expiration dates." Most of the sites listed are distinctly NSFW, among other places, but the list includes some of the largest retailers, too, notably Amazon and Wal-Mart.
The worst part about them being somewhat vague about which sites are compromised (amazon.com? .uk? .eu? .mars? .SetiAlphaV?) is i need to download the list now to check if my username, password and especially credit card number is on there and doing so potentially makes me a criminal. I'm not going to cancel my credit card on the off chance.
When this kind of things go down a news source should show ONLY the usernames so at least people have a hint that they need to cancel their credit cards.
That is pocket change compared with the 38 millon Adobe users of last year or the 7 millon dropbox users last october.. Even Sony hack of the data of internal users were in those order of numbers.
If you are going to do your own round counts, there are better ways to make it so you can't use hardware to attack your system. One trivial way with hashes is to xor the 1st byte with 0xaa on the 12th round. That alone means anyone building hardware or a GPU approach needs to take that odd step into account and that should about double the work needed by a GPU using today's techniques for optimisation. Another thing that works is to use a different table. For example MD5 uses an internal table that is something like 256*sine((0..255)/256.0). A simple swap of two bytes somewhere in the table means it is incompatible with off the shelf solutions and should be the same strength. There is a risk that doing this will cryptographically weaken the hash. For example if you use the XOR trick too early or too often in the rounds, you end up forcing bits to a known state and that makes it much weaker much like messing with S-boxes in DES does and for the same reasons. Moving around values in large tables tends to be safe as does some conditional byte manipulation in later rounds assuming you are doing more than the standard count. A great way to find out what doesn't work is write a md5 like function with 32 bits and just a few rounds. That can show lots of tweaks are very bad ideas.