can someone please make a hall of shame for all the big Companies which where hacked! i think there are quite a lot by now.
Hacking is inevitable.
While 0-day vulnerabilities will always get the best of some companies, there are some security breaches that are just due to plain negligence of the company.
I believe I recall Sony getting hacked, and tons of plain-text credit card numbers were hacked. It was discovered that Sony didn't even follow even the most simple of PCI compliance.
It's things like that that deserve the "hall of shame"
While 0-day vulnerabilities will always get the best of some companies, there are some security breaches that are just due to plain negligence of the company. I believe I recall Sony getting hacked, and tons of plain-text credit card numbers were hacked. It was discovered that Sony didn't even follow even the most simple of PCI compliance. It's things like that that deserve the "hall of shame"
I have a PSN account and indeed had an account during that event. There was tons of wild speculation about what data was breached, but there was no evidence that credit card numbers were included. Sony unfortunately only fueled those rumors by refusing to comment on the specifics, but I can assure you that if they were storing "tons of plain-text credit card numbers" there would have been a legal shitstorm the likes of which we have not seen in many a year, including a class-action lawsuit. I have yet to receive any invitations to participate in any such lawsuit.
Is there even any reasonable excuse for limiting the length of passwords to something less than hundreds of characters?
There's no reason to limit the length of passwords whatsoever, except perhaps to be sure you're not trying to hash 20mb of text.
I won't say 20MB passwords wouldn't pose any practical problems, but the hashing itself isn't really an issue. A simple bcrypt test on my laptop (w/work factor 12) gave me these numbers:
1KB: 0.279 secs
1MB: 0.277
10MB: 0.293
100MB: 0.473
1000MB: 2.169
Getting the 1GB string allocated in Python locked my system up for longer than the 20 loops over bcrypt did. :)
I should probably find a machine with a little more RAM to test 10GB...
At least on the web, hashing isn't usually done locally (ie, in Javascript).
this doesn't add extra security - the first hash becomes a substitute password. A cracker could modify their steam account to take said hash as input and sent it directly over the wire.
At least on the web, hashing isn't usually done locally (ie, in Javascript).
this doesn't add extra security - the first hash becomes a substitute password. A cracker could modify their steam account to take said hash as input and sent it directly over the wire.
It doesn't remove any security, either. If you perform a hash on the server that sends an arbitrary input size to a fixed number of bits, the attacker needs only to try O(2^n) different inputs where n is the number of bits of that hash. By using a hash with at least n bits as a substitute password, there's no less security. It does mitigate the DoS vector, however.
Ubisoft should have a look at LaunchKey (https://launchkey.com) which went out of private beta yesterday. Passwords being compromised should be a thing of the past.
There's no reason to limit the length of passwords whatsoever, except perhaps to be sure you're not trying to hash 20mb of text.
I won't say 20MB passwords wouldn't pose any practical problems, but the hashing itself isn't really an issue. A simple bcrypt test on my laptop (w/work factor 12) gave me these numbers: 1KB: 0.279 secs 1MB: 0.277 10MB: 0.293 100MB: 0.473 1000MB: 2.169 Getting the 1GB string allocated in Python locked my system up for longer than the 20 loops over bcrypt did. :) I should probably find a machine with a little more RAM…
The primary problem here would be a DoS attack against a web server that accepted that much data in a submission form.
edit: also, merely saying "bcrypt" isn't quite sufficient; we'd have to know what work factor you were testing with. bcrypt with a work factor of 2 is vastly different in performance from bcrypt with a work factor of 12.
The other companies aren't really trying to compete with Steam per se, they just want to inject their own custom babysitter to analyze your computer and see if they're complying with their rules. When you open a game from Steam that's produced by one of these companies, it chains in its own loaders and achievements and stuff. It totally sucks, and it's a terrible end user experience. It'll be exciting when the fogies…
I think they are probably more interested in avoiding the ~15-30% (rumored) cut that Steam takes for digital sales of their games. And I know in EA's case, they want to sell DLC through their game, not through Steam's client specifically to avoid that charge (that's the reason some EA games were removed from Steam when Valve changed their policy on the matter).
They do this even on games purchased directly through Steam. It's obviously not about cutting out Steam, because they still facilitate their sales via Steam and presumably are still obliged to render commissions. As Ubisoft says in their own announcement, UPlay did not accept payments directly; distribution channels like Steam or physical retail were still required to obtain the games.
I received an email from Ubisoft and assumed I was being phished. They are not doing a good job of fixing the problem here.
They should have a cert on the splash redirect page. I wasn't sure if ubi.com was actually Ubisoft. Even worse, the email I got had some terrible font - practically unreadable. Those two factors combined did not make me feel that giving them my password is a good idea.