Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Ubisoft hacked, account data compromised

support.ubi.com

Post reply on HN
Print view View original

91–100 of 104 posts

Re: Ubisoft hacked, account data compromised

#91

Post by nknighthb »

thaumaturgy wrote: post #87
nknighthb wrote: post #83

Earlier quoted context omitted.

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.

> we'd have to know what work factor you were testing with

Parentheses are not made to be ignored.

But I don't think it matters, which is why it was a parenthetical. The point is the relative differences between different sized strings, not the absolute timings.

Re: Ubisoft hacked, account data compromised

#92

Post by Spittie »

thaumaturgy wrote: post #87
nknighthb wrote: post #83

Earlier quoted context omitted.

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.

Isn't the password length check done locally on the machine (with javascript or similar)? If so, an attacker could easily ignore that check and send as much data as he want.

The check on that should (and, AFAIK, is) done server-side, with the server closing the connection after a certain amount of data or time.

Re: Ubisoft hacked, account data compromised

#93

Post by thaumaturgy »

nknighthb wrote: post #91
thaumaturgy wrote: post #87

Earlier quoted context omitted.

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.

> we'd have to know what work factor you were testing with Parentheses are not made to be ignored. But I don't think it matters, which is why it was a parenthetical. The point is the relative differences between different sized strings, not the absolute timings.

Whoops, sorry -- dunno how I missed that.

Re: Ubisoft hacked, account data compromised

#94

Post by nitrogen »

nknighthb wrote: post #83
quaunaut wrote: post #26

Earlier quoted context omitted.

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…

Doesn't most of bcrypt's work come from rehashing its output? So it only has to touch the 1GB input once, right?

Edit: after reading https://en.wikipedia.org/wiki/Bcrypt#Algorithm, it looks like bcryt's make-work loop does refer to the key in each iteration. I can't tell on a cursory reading whether access to the original key can be memoized, though hashing the large input once before passing it into bcrypt would have the same effect.

Re: Ubisoft hacked, account data compromised

#95

Post by nknighthb »

nknighthb wrote: post #83
quaunaut wrote: post #26

Earlier quoted context omitted.

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…

Purely in the spirit of "because I can", I fired up a 244GB EC2 instance:

1MB -- 0.310421895981 seconds

10MB -- 0.317299044132

100MB -- 0.409169948101

1GB -- 1.3299703002

10GB -- 10.8254830956

100GB -- 133.936514747

I noticed during the 100GB loop that the process oscillated between 100GB and 200GB, making me suspect that the 100GB string is actually being copied somewhere, which is inefficient and surely has a significant effect on the timings at larger string sizes. As such, I didn't go for a 200GB string.

And just 'cause most of us don't see 200GB python processes every day:

https://dl.dropboxusercontent.com/u/14571816/python%20200gb....

Re: Ubisoft hacked, account data compromised

#96

Post by zachlatta »

deelowe wrote: post #55
zachlatta wrote: post #47

Earlier quoted context omitted.

Mostly because the interface is clunky and I'd rather not be forced to have my passwords stored on a company's servers.

Ahh. OK. One small nit. Passwords aren't stored, the has is. If you forget your lastpass password, there's no way to retrieve them. I'm OK with this, which is why I continue to use lastpass. That said, the interface is definitely terrible. It could use a refresh at this point.

What does "the has is" mean? To my understanding, encrypted passwords are stored on the company's servers and they are decrypted on the client-side. I don't know how they're storing their data, but I do know that we never know what the future holds. Those passwords that may be secure on their server today may easily be broken tomorrow.

I'd rather by in control of my data.

Re: Ubisoft hacked, account data compromised

#97

Post by kibibu »

Brandon0 wrote: post #72
cookiecaper wrote: post #38

Earlier quoted context omitted.

Right, as the OP said, there is no reasonable excuse to limit character intake to less than multiple hundreds. I agree that some limit is sensible just to ensure someone doesn't insert War and Peace (or base64-encoded binaries or whatever) as their password.

I was using War and Peace -- now I have to go change my passwords. Thanks!

...a dependence of which we are not conscious.2

Re: Ubisoft hacked, account data compromised

#98

Post by misterdai »

zachlatta wrote: post #13
Zikes wrote: post #6

Earlier quoted context omitted.

Everything else being equal, Steam may well end up being similarly hacked in the future. The big difference with them is that they use 2FA, so even if your hashed password were stolen and cracked, they still would not be able to access your account. Edit: I just went through Ubi's password change process, they also restrict password lengths to 8 to 16 characters. Annoys the heck out of me when companies do this.

Is there even any reasonable excuse for limiting the length of passwords to something less than hundreds of characters?

Only the support issue, but then I'd have thought that people using really long passwords as normally the ones who'll make an effort to remember / store them. They mention "Encrypted passwords", which would vary the amount of storage required in their database and also make the passwords retrievable if the attacker had gained access to the key / algorithm etc...

I'd had preferred if they used a one way hash instead, obviously with a secure hash algorithm, uniquely salted and rehashed multiple times. All passwords would then be the same length when stored and users wouldn't have to have such a low maximum limit.

There are worse offenders for low character limits, like Adobe with a 12 char maximum. Used to be a site that listed some, just a shame it's no longer available http://web.archive.org/web/20100526105638/http://www.weakpas...

Re: Ubisoft hacked, account data compromised

#99

Post by alexjeffrey »

just2n wrote: post #85
alexjeffrey wrote: post #84

Earlier quoted context omitted.

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.

no it doesn't remove any security, but why implement a feature that doesn't add anything?

Re: Ubisoft hacked, account data compromised

#100

Post by just2n »

alexjeffrey wrote: post #99
just2n wrote: post #85

Earlier quoted context omitted.

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.

no it doesn't remove any security, but why implement a feature that doesn't add anything?

It does add something: users can use any password they want. Any unicode string. You just UTF-8 encode then locally hash into a constant size. This alleviates the issue mentioned in the grandparent that supporting arbitrary length passwords introduces a DoS vector, especially when a slow hash is used on the server.
Post reply on HN