Slashdot Mirror
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.
And even if ALL 13000 were Amazon, that is a tiny percentage of accounts. It would be nice if they had posted the link so you could look for your name. Now it is hidden so the people least likely to be on the list (those with enough clue not to install the malware) can find it in a few minutes, but those most likely to be on the list will have no clue how to...
How does this stunt make the world a better place? I just don't like online vigilantism. I also hate Guy Fawkes masks.
Most of the listed sites have far more than 13,000 registered users, so access to the member database of just ONE of the sites would have yielded a much larger dump.
Also, some of the sites store only a properly salted, modern hash of the password, so there's almost no way to get passwords from the sites' servers.
It's pretty clear the hack is in the client side. We may have a look to see of the logs go back far enough to tell us which browser version, OS, and toolbars or addons those members were using.
Source - I designed the authentication and authorization systems for some of those sites.
13,000 Passwords, Usernames Leaked For Major Commerce, Porn Sites
Replacing the word "and" with commas pointless, annoying.
systemd is Roko's Basilisk.
The list that was posted has apparently been removed (if you can get to the site, which seems to be under heavy traffic with people looking for it). Furthermore:
Malware explains the odd collection of websites, relatively small number of accounts, and supposedly-plaintext passwords. So anyone affected who changes their password will just have that new password picked up unless they've exorcised their computer.
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.
Took me less then 5 minutes to figure out this is a click bait scam using collections of older password leaks and money for clicks URL referers. And the 'news' are eating it raw, generating fear and helping it spread. Which is exactly how this scam was designed to work.
Its not a security failure if they flood your network from the outside....You cant stop these attacks, only mitigate them.
Good-bye
DataBreaches.Net is carrying an article saying that the leaks are nothing new.
http://www.databreaches.net/verifying-leaks-uncovers-fake-leaks/
"Posted by @Cyber_War_News to Pastebin today:
Today has been interesting, to say the least.
Skipping all the bullshit lets get right to the main stinky shit.
Anonymous twitter user @AnonymousGlobo announced earlier today this:
https://twitter.com/AnonymousGlobo/status/547426305151860736
https://twitter.com/AnonymousGlobo/status/548537460691857408
Now after working with data leaks for years now it became clearly obvious to me that this was fake. why?
because real leaks do not get combined, real leaks often have a common format, the targets attacked have accounts leaked daily from phishing and other simple methods."
[more snipped]
Dependency: Of course the people who can't afford to keep their CC balance at zero end up paying for my peace of mind via increased interest rates. Ultimately CC's are an unfair burden on the "working poor" and become "just another bill" when they inevitably hit their limit (been there, done that). The sad fact is that if everyone at every point in their life could afford to keep the balance at zero nobody would pay interest and CCs would not exist.
That last sentence is false and shows you don't fully understand what you're discussing. The merchant is charged a fee, usually a small percentage of the transaction, each time you use your credit card. Even if you never personally pay interest because you pay in full each month, the bank issuing the credit card is making money from your use of that card.
Incidentally, this is also why some small, local, mom-and-pop stores won't accept a credit card unless your total purchase exceeds a certain amount. The fee they must pay isn't worthwhile to them if the transaction is too small. Larger stores are better able to absorb it and just consider it a cost of doing business.
It is a miracle that curiosity survives formal education. - Einstein
Just don't spend more money than you have...
Easier said than done if you're always broke before the next payday. And no, that scenario doesn't automatically mean you're a lazy or that you squander your money. Quite the opposite, it generally means you work 60-80hr weeks in retail or some other minimum wage (or less) industry. When the shit-box car that takes you to work dies a CC is normally the only way it can be revived/replaced.
The vast majority of the "working poor" know it's a financial trap when they get the card, but sometimes in life deliberately walking into a trap is the best option you have, thankfully I haven't been in that position for over 20yrs now.
And did you exchange a walk on part in the war for a lead role in a cage? - Pink Floyd.
Both brypt and scrypt would PROBABLY work, especially bcrypt, but they're designed for a different use. What you want for password storage is confidence that if the bad guy gets F(plaintext,salt), (the hash) they can't derive the plaintext. It's a one-way trap door - you can compute the hash from the plaintext password, but not the other way around. You do not care about any aspects of the output, other than that it can't be used to infer the input (and that it has a guaranteed reasonable maximum length).
For a key derivation function, it's ALL about the output. You're trying to create output that has particular attributes, such as pseudo- random bits, long length, and bonus points if they length can be extended to go on forever.
Key derivation algorithms sometimes work okay as hashes (for password storage), but almost by accident. That's not what they're designed for. To achieve the very different goals of KDAs, they tend to be much more complex, and therefore much more likely to contain subtle undiscovered weaknesses. I'd rather use something designed for the job at hand. I wouldn't, however, say someone is WRONG to use bcrypt for the purpose. If a student turned in a project that used bcrypt for password storage, I wouldn't mark down their grade. It's just not my personal preference.
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.