Ubisoft hacked, account data compromised | Hacker News Reader

Ubisoft hacked, account data compromised

support.ubi.com

120 pointsbobwaycott101 comments

I wouldn't care so much about this, except that I am often essentially required to give my data to Ubisoft (and other third party publishers) in order to buy/play their games. EA, you're no better.

Why are all these companies adamant about trying to bootstrap their own services. It's maddening, and it only causes things like this to happen. Steam exists, and it's amazing. Stop trying to do better -- you won't.

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.

The Steam forums were hacked in Nov 2011. The hackers got access to a DB with Steam users' personal information.

http://arstechnica.com/gaming/2011/11/valve-confirms-steam-h...

Valve's game development servers were also hacked, and Half Life 2's source code was leaked before the game even launched.

No company is immune from hacking, the best anyone can hope for is secure hashing functions are in place and that financial and user account data are properly separated.

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

No.

A potential common excuse may be, "No one will remember a secure password in excess of 16 characters, we are trying to minimize support volume", but this is not a "reasonable" excuse.

Yes. It's a DoS vector. The question is, what is a reasonable limit - and 16 characters fails horribly in that section.

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

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...

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....

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.

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.

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.

now enter the first 72 characters of that password in the bcrypt verification function and it'll still say it's correct. bcrypt is a valid technical reason to limit passwords to 72 characters.

You could really support an arbitrary password size by locally hashing the password to a length at least as long as the one you store in the database to preserve entropy, then send the fixed length hash as the user's "password", and hash it again on the server using something slower, like PBKDF2 with a few thousand rounds.

How do you think hashing functions work?

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.

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.

arbitrary length passwords simply aren't necessary though, and are unlikely to be used - if you were to cap passwords at, say, 128 characters, who would run into that limit?

I'm not arguing that if this functionality were already present in an app that you should remove it; however if it's not there already there's very little value it could add that would justify any development time. That's just my opinion though.

The only reasonable restriction is in overall POST body length. I recall an exploit once on node.js where unreasonably large POST requests could DDOS a server with minimal effort.

Well, that and the server having to hash a huge password.

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...

None that wouldn't be better handled with a warning of "excessive password complexity, we're not sure you'll remember this". Even truncating all password entries (create/change and auth) and simply taking the used subset would be better than blocking me from using my intended password.

Hmmm... if your password was password30jf0sd09jga09ja0i9sdfasi09djf0-sdj9faspiodjf and they only used the first 8 characters, you'd think you had a strong password, but would really have a very weak password. Hashing then truncating as discussed above would be much safer.

Really no reason to truncate after hashing. The output size of any cryptographic hash function should be more than small enough to send down the wire and hash again properly.

Really though, just reject passwords over a few KB. Nobody will ever notice that limit except for people trying to fuck with you.

I have mixed feelings about that. On the one hand, I fully agree - I hate having all kinds of junky game clients running on my computer when I ought to just be able to have one, Steam, which is obviously doing a decent job.

On the other hand, I think that competition will drive Steam to be better (or maybe, just maybe, result in something better than Steam), and so I don't necessarily want the other companies to stop trying to compete entirely, either.

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 in charge of these companies die out. They seem to have difficulty grasping the concept of computers and digital distribution.

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.

This isn't really a market that benefits from competition doing anything less than the same the same thing, though. Steam is acting as more of a dumb distributor than a publisher, and are an established player. All Ubisoft and EA have is their own titles. They're not going to attract indie players, and they're not going to attract other publishers' work if all they're trying to do is utilize their titles to garner users. In other words, they're not currently trying to be the next Steam, they just want to take a bite out of Steam.

If either of those companies wants to make a real effort at getting a distribution platform off the ground by competing with Steam on the developer side and the pricing side, then that's competition I'm willing to see. As it stands, they're simply trying to leverage their developers' work into membership.

Can't speak for Ubisoft, but Origin sells games not published by EA. I think right now they sell Sega, Square and Warner Brother games. They also sell physical copies of games not published by them, including some Valve games. They're growing their catalog.

I agree. However, in every current case Steam is just making all these other platforms look bad.

That's a pretty lousy, defeatist attitude to have.

"Girls, stop trying to be as good at math as boys -- you won't."

"Google, stop trying to do better than AltaVista/HotBot/Lycos/Excite -- you won't."

"Apple/Linux, stop trying to do better than Microsoft -- you won't."

"PlayStation/Xbox, stop trying to do better than Nintendo -- you won't."

"Tesla, stop trying to do better than Toyota -- you won't."

"Renewable energy companies, stop trying to do better than fossil fuels -- you won't."

"User-hostile dinosaur companies. Stop trying to do better than..." Oh wait.

Relying on one service is good for no one. Specially consumers.

It's better for my hard drive and RAM. It's bad enough having just one program on my PC whose only purpose is to allow me to play the games I've purchased legitimately, I don't want any more.

It's also better for That One Service... but that's besides the point. ;-)

Here is a good list of DRM free Ubisoft games: http://www.gog.com/catalogue?search=Ubisoft

This doesn't matter though in regards to personal information. Any service where you buy the game will have your information for the sake of enabling purchase. Steam is no better here, and even GOG. If either of them is hacked - your personal info will be leaked.

This is what happens when companies try to own the customer relationship and use their own customers as strategic weapons. Steam isn't a neutral party.

Let's play the guessing game: by "encrypted" they mean MD5'd?

I received an email from them - the password was included in the email, in plaintext.

So I don't know exactly what they mean, but it's at best symmetric encryption.

I've got an account with them under two different email addresses, and have gone through the password change process with both. In neither case did I receive an email with my password in it.

Symmetric Encryption means both sides can access the data. It's different from using a hash (like MD5 or the stronger SHA series) in that it can be reversed given the key.

Ouch... that's oversimplified... Here: https://en.wikipedia.org/wiki/Symmetric-key_algorithm http://cseweb.ucsd.edu/~mihir/cse207/w-se.pdf

By encrypted they probably mean they applied the most potent of all cryptographic techniques: base64 encoding!

It would be hilarious if this is what it was and hackers couldn't figure it out and abandoned the hack because they're trying all these advanced techniques and none of it is working.

You must mean UTF-8 encryption

rot13

To add insult to injury, another (though less severe of course) security issue is this - I went to the "change password" page per their recommendation, and typed my email. Usually, security best practices say that you should not volunteer any information for a potential attacker, e.g. don't tell the user if an email was sent or not, as this can be used for example to eventually construct a list of all their user's emails (Although they have captcha protection so it's not really feasibly or at least less likely in a reasonable cost, but still, I can find out if John Doe has a Ubisoft account or not, e.g. if I'm Joe's manager who works for a competitor, and he swore last night that he never plays Ubisoft games, busted!).

So this is what I got from their change password screen:

"No account was found matching those entries. No email will be sent."

So I'm glad I learned that I don't have my password compromised. but I think someone at Ubisoft need to take web security 101 again

p.s. Who encrypts passwords anyway? isn't there a consensus to hash using bcrypt / scrypt + random salt?

I'm going to speak strongly against the prevailing view in the security community here: a forgot password email/username oracle is not an issue. Not in any way, shape, or form.

Why? Because if I go to register an account with a given email or username, it's going to tell me if that account is already registered! Unless you make multiple accounts with a given username/email possible (please, please don't do that), the forgot password oracle is a non-issue.

You lose absolutely nothing by saying "this email does not exist", and you gain a tremendous amount of user friendliness.

How about this: when you register an account with an already existing email, the website returns the same message as it would if the email didn't already exist: "The account have been created, but needs to be activated. Click on the link in the activation email that has been sent to your email address.". Now, the email that is actually sent says "Someone tried to create an account with your email address. If it was you, we remind you that you already have an account at our website". If the email does not exist, then usual activation email is sent.

This way, we don't leak the emails of registered users. If we use emails as usernames, we don't leak usernames either.

This does seem like a reasonable approach, but would definitely need a rate-limiting system/opt-out to avoid intentional activate-mail DoS to the actual address owner.

Might also help whoever has foo@bar.com and similar, too.

I've never thought of that approach, and of course, how to go about limiting that as an attack vector. We so often try to make it as easy as possible to signup, we forget to think of it as a potential security leak.

Thanks for this insight.

No one encrypts passwords. They just refer to one-way hashes, typically MD5, as encryption.

Unfortunately, I have to disagree.

In fact, there are some large vendors of software that truly use encryption instead of some form of one way hashing. Sadly, I have to deal with software like this and there's no chance it's going to change any time soon.

It's a built-in feature of ASP.Net's membership provider (user accounts for those not knowing MS's Enterprise Obfuscation Naming And Extension Standard).

But that behavior is configurable.

Also, the password is limited to 16 chars.

They sent a notification email to every customer asking them to change their password. The email includes the user's current password.

I know this because I received such an email-- intended for someone else who accidentally used my email address for their account. So not only is Ubisoft storing raw passwords and sending them via email, they're not verifying email addresses during account creation.

No way, really? According to the article they claim to "encrypt" the passwords (they actually mean hash). Any way you could post the contents of the email (minus the personal details)?

I think he's misunderstanding the email:

>As a result, we are recommending that you change the password for your account: dclowd9901

All I see is the plaintext representation of my username.

Ah, glad to have that clarified. The username in the misdelivered email I received looked very much like an attempt at a memorable password, not a username. Thanks!

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.

I just got an email about this from Ubisoft, with a link to change my password. Yet another incident to prove that unique passwords and utilities such as RoboForm / Dashlane / Lastpass are a necessity.

I was happy that they included the "you should change your password on all other websites if it is the same" line.

I find that's the biggest hurdle that average users can't grasp, it's not about one website getting hacked.. it's that if your ubisoft password is the same as your email address password then they can now log into your email address, which means they can probably take over every online account you have.

As an alternative, you could GPG a text file with all passwords and use...

  hexdump -n 16 -v -e '/1 "%02X"' /dev/urandom

...as a password generator

    openssl rand 48 -base64

Ah, yes. Much shorter and more effective ;)

I built an extension to use PBKDF2 and some other cleverness to generate predictable passwords for websites because I was tired of needing "random" passwords for every site and some kind of password keeper that stored them. I'd rather generate the password when I need it, and to do so from a password I have memorized, but which isn't written down or used anywhere else.

I'm using

  cat /dev/urandom |base64 |head -c20 && echo

Try

    pwgen 20

I've been looking for a Lastpass alternative forever. Had no idea Dashlane existed, thanks!

I was inspired by a blog post I saw here and ended up creating a chrome web store app and an android app for creating site-specific passwords based on a master password.

https://github.com/kzahel/passwordmaker https://github.com/kzahel/passwordmaker_android

I simply don't trust 1password, lastpass, etc.

The one problem I have is that many websites place artificial restrictions on password length, types of non-alphanumeric characters, requirements on number of numeric digits, etc. It would be nice if there were an updated collaborative list of these artificial restrictions somewhere.

Currently I simply update the password generator to conform to these restrictions whenever I need to create a password for a dumb website.

Why don't you like lastpass? Genuinely curious. I've been pretty happy with them.

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.

My apologies. You are correct. I wrote hash(actually typed "has") when I really meant that they are stored encrypted. I forget the algorithm that's used, but my understanding last I looked into it, the encryption lastpass uses is the best available.

Dashlane's interface is really nice compared to Lastpass & RoboForm

Dashlane is pretty nice, I'm using it and RoboForm, which I've owned for years.

How is RoboForm? I've never used them before.

Showing it's age. They continue to update it, but it's definitely lacking in usability compared to Dashlane.

> No personal payment information is stored with Ubisoft, meaning your credit/debit card information was not at risk from this intrusion.

Sure they can't read the data right of the disk, but what about a MITM? If the intruder had access to the application server, there's a good chance the credit card data was in memory at some point. If the data ever touches the server memory in an unencrypted form, the intruder could have it...

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.

Deleted comment

That's a fake account.

Not sure if serious ...

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.

It shouldn't be a hall of shame for companies being hacked, getting hacked is thing you can only mitigate not prevent.

The shaming should be for storing your sensitive data in an insufficiently secure manner. If a company used scrypt to hash their passwords then they would essentially have no issue with getting hacked.

Already there: http://plaintextoffenders.com/

This would just lead companies not to disclose cases, which would be far worse for everybody.

Openness about this kind of thing should be encouraged.

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"

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.

Yay!

Reply on news.ycombinator.com