Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Trion Worlds' Rift Account Database Compromised

Soulskill posted about 2 years ago | from the level-up-your-firewall-skill dept.

Security 88

New submitter Etrahkad writes "Trion Worlds, publisher of MMORPG Rift, has announced that somebody broke into one of their databases and gained access to user information. First Sony and now Rift... my identity has probably been stolen several times over, now. From the e-mail: 'We recently discovered that unauthorized intruders gained access to a Trion Worlds account database. The database in question contained information including user names, encrypted passwords, dates of birth, email addresses, billing addresses, and the first and last four digits and expiration dates of customer credit cards. ... there is no evidence, and we have no reason to believe, that full credit card information was accessed or compromised in any way." Are game companies not concerned with preventing these attacks?"

cancel ×


Sorry! There are no comments related to the filter you selected.

Yay (4, Insightful)

dlb (17444) | about 2 years ago | (#38473528)

To the cloud...

Re:Yay (1)

jhoegl (638955) | about 2 years ago | (#38475158)

Shouldnt this be modded hilarious?
Im pretty sure it should.

Re:Yay (1)

Anonymous Coward | more than 2 years ago | (#38478288)

It's implied by "To the cloud..." being marked as "Insightful"

Prevention (5, Insightful)

grommit (97148) | about 2 years ago | (#38473546)

Granted, it could be a simple ROT13 but the mere fact that the passwords were "encrypted" and that the data didn't contain the entire credit card number indicates that the company or somebody inside the company at least put a little bit of effort into securing the data. Unfortunately, securing data is hard and it only takes one oversight to make it vulnerable. The true test will be what the company does now that the breach has occurred.

Re:Prevention (5, Informative)

tguyton (1001081) | about 2 years ago | (#38473670)

The entire email from Trion:

We recently discovered that unauthorized intruders gained access to a Trion Worlds account database. The database in question contained information including user names, encrypted passwords, dates of birth, email addresses, billing addresses, and the first and last four digits and expiration dates of customer credit cards.

There is no evidence, and we have no reason to believe, that full credit card information was accessed or compromised in any way. We have already taken further action to strengthen our systems, even as we, with external security experts, continue to research the extent of the unauthorized access.

You will notice on your next log in to our website that you will be required to change your password, and existing Mobile Authenticator users will also need to reconnect their Authenticator. When you log in, you will be prompted to provide a new password, security questions and answers, and be given the option to connect your account to our Mobile Authenticator to enhance your account’s security.

If you have used your username and password for other accounts, especially financial accounts or accounts with personal information, we suggest you change your passwords on those accounts as well. We recommend that you carefully review your statements, account activity, and credit reports to help protect the security of those accounts. If you need information on how to obtain your credit report or believe any such accounts have been breached, please visit for more information.

You should have continued, uninterrupted access to RIFT, and we do not anticipate any disruptions to your playing time.

Nevertheless, if you own the RIFT game, you will be granted three (3) days of complimentary RIFT game time once you update your password and security questions.

Additionally, once you update your account and set a new password, your account will be granted a Moneybags’ Purse, which increases your looted coin by 10%, even if you have not yet purchased RIFT.

Please log in to [] (and we recommend that you copy and paste this link into your browser to access the site) to update your password, security questions and Authenticator.

We apologize for any inconvenience this may have caused you. If you have further questions, please visit our website,

– The Trion Worlds Team

Trion's been pretty good about security from what I've seen, and I definitely appreciate them being upfront about the breach. Giving people a few days of game play and shinies will probably generate some good will as well.

Re:Prevention (2, Insightful)

Derekloffin (741455) | about 2 years ago | (#38473676)

Passwords should actually be hashed and preferably hashed and salted, not encrypted, but points for at least trying.

Re:Prevention (2)

mlts (1038732) | about 2 years ago | (#38473800)

I can't remember the standard for this, but passwords shouldn't just be hashed and salted, but run through a number of rounds to slow down brute forcing.

Even better, why can't there be dedicated appliances like hardware HSMs for public/private key encryption that companies can use to store account password hashes there? This way, an intruder would have to have physical access to the box in order to extract the hashes.

Re:Prevention (1)

Mortimer82 (746766) | about 2 years ago | (#38474272)

Yes, there are quite a few things to keep in mind for password hashing, when it comes to cryptography and hashing, it's always best to go with solutions which have been thought up by people who are properly familiar with the subject. Only fools try think up their own scheme and don't get it critically reviewed by peers first.

I use this for my PHP projects: []

I'm not clever enough to know for sure it's sound, but I am fairly confident it is based on the technical explanation on the website.

Re:Prevention (0)

Anonymous Coward | about 2 years ago | (#38476390)

Am I the only one who read this as "PHP Ass"? On a similar note, I always read "Keep Ass" as well, despite their preventive CamelCasing.

Re:Prevention (1)

AJH16 (940784) | about 2 years ago | (#38474276)

You don't seem to understand what you are talking about here. Extra passes of hashing wouldn't do anything that a good salt wouldn't. Running multiple encryptions to slow brute forcing is an idea where one side is not known and so having more than one pass prevents a single decode attempt from resulting in a recognizable plain text. The convention is to do it three times so that you can't simply look for a meet in the middle of a bunch of passwords encrypted once and a bunch of encrypted passwords decrypted once.

With hashing however, it is one way, the brute force attack is simply to run the hashing algorithm for a bunch of inputs until you get one that matches the output. Running multiple such hashes does very little as it adds as much time to an individual processing as it does to a crack attempt. Using a sufficiently complex salt would accomplish the same thing.

As for using a hardware key control, they are designed to hold master keys, not to hold hundreds of thousands or millions of user's records. You could use it to store the encryption key to decode encrypted data in your DB, but if someone gets in to your DB itself, the system will happily decode it for the attacker and there isn't much you can do about it. They are more designed to stop someone from walking off with the data files or extracting the key, but if they compromise access to the data via a legit means, you are up a creek.

You might be able to try and adapt a hardened physical box to do simple validation checks with it separately hardened to not allow the hashes to ever get out (ie, pass just the hash to the box and look for verification back that it is valid for a user) but you are going to end up hitting that box pretty hard for something like an MMO. You might gain a little, but I'm not sure you would gain much over simply putting it in a separate DB schema with a signed sproc to do the verification as a simple match of hashes. Something along the lines of a securePassHash schema with a cert signed sproc CheckUserHash(userID,hashVal) that returns true or false and another SetUserHash(userID, hashVal).

Re:Prevention (1)

mlts (1038732) | about 2 years ago | (#38474918)

Extra passes of hashing seem to help. The venerable UNIX crypt(3) did a number of rounds to make for one CPU second of calculations for each password check. TrueCrypt performs a number of rounds when hashing. Same with OS X and iOS. Of course, due to CPU power doubling as per Moore's law, using number of rounds/extra passes is a losing battle. Instead, just as mentioned above, a good salt needs to be part of the hash algorithm.

The last part is what would be snazzy if designed -- a hardened physical box that would store the hashes. The reason for this over a separate DB schema (and hardened machine to serve it on) is isolation. The hardened hash checker would respond to a limited amount of inputs, and would impose an increasing time delay if a certain user/hash keypair keeps getting asked for authentication and failing. This way, an attacker couldn't just take a list of userIDs and brute force their way with CheckUserHash queries. For a MMO, one could add functionality into the hardened box to allow for multiple boxes to securely replicate hash data (database level, or on the OS level with rsync over ssh.) This would be also improved by using SSDs for the database (so random small reads are handled quickly.)

Re:Prevention (1)

AJH16 (940784) | about 2 years ago | (#38475610)

Yeah, I guess I shouldn't say that it won't do anything to run multiple hashes, but you are only increasing your brute force time by the same factor as you are increasing your individual run time. That isn't a very effective security mechanism since you are only lengthening the process by O(1). It would prevent the use of rainbow tables that had been run for a single pass, but again, a good salt would do the same. The core issue is that brute forcing a hash is simply run hash on A, does result match? If yes, use A, if not, increment A and try again. Store your result and move on. If you have a large DB, you use the table for each record. Give each password it's own salt, and you now have to individually crack every single password hash by itself. It renders the attack pretty difficult.

The separate platform for isolation would be nice and certainly adds a little security (and is actually likely the way I would do it if I was designing the system), I was just trying to highlight how simple it would be to increase the security to prevent this kind of thing even without such a device. You could also have an internal counter per day in the sproc that would prevent it from running more than a given number of times for a given record as well. It is a very solid addition to my proposed scheme. In general, your DB server should provide a pretty good level of hardening though as you could encrypt the data in the given schema with a symmetric key that only the signed sproc has access to. Thus, there would be no way for an external attacker to compromise it without altering the query. You are effectivly hardening the input to that schema of the DB to only be possible through the hardened interface of the signed stored proc. The main thing the hardened physical box would give you is the inability to get an encrypted data dump that would contain the information where they could try to brute force the symmetric encryption, though I wouldn't be too worried about that happening either.

Re:Prevention (0)

Anonymous Coward | about 2 years ago | (#38475900)

I hate to admit that I'm partial to the encrypted hash appliance. The main reason is that I have a prototype of one that I designed a few months ago to show how hashes should be stored and stored right. Isolating the hash data on a hardened box mainly provides protection against an intruder dumping the whole database. However, it also provides some more things that may seem minor, but can help greatly mitigate, or just detect a threat:

1: Limiting the amount of wrong validations to an account in a period of time will cut down on brute forcing. We really don't care to limit the amount of times a user can authenticate if they get their password right, but every time they get their password wrong, there should be a delay, then perhaps a return code that the account is locked out for a while (say 15-20 minutes.) By using a 5 wrong guesses and a lockout every 15 minutes, then another 5 guesses, an attacker is limited to 480 different passwords a day. This would be further limited by an exponential delay algorithm. As for denying access to an IP address range, that is the job for the Web server and the application.

It also provides defense lower in the stack. Most Web applications if compromised would allow access to the username/password hashes, or just allow for the intruder to get around time delays and lockouts. By having this done on a separate box with no connections to the outside other than this interface, it means that no matter how much control an intruder has, they will not be able to get around the appliance's safeguards (barring physical attack, of course.)

Re:Prevention (1)

AJH16 (940784) | more than 2 years ago | (#38480116)

Yeah, I guess I was just saying all the same things can be done with the DB server and signed certs and encrypted DBs directly. You can make it so that it counts only wrong attempts and resets at the end of the day. You could even set a duration to lock it out for. You're still at a lower point in the stack since the web server is still having to call out to the DB server. Effectively, from a security stand point, if you were to put the schema on a different DB server, it would be doing the exact same thing as the hardened box. You could effectively just wire the hardened box web services directly up to the queries and have no other code.

Re:Prevention (0)

Anonymous Coward | about 2 years ago | (#38476298)

> Yeah, I guess I shouldn't say that it won't do anything to run multiple hashes, but you are only increasing your brute force time by the same factor as you are increasing your individual run time.

The only case where there's a 1:1 increase is if they already know the password. If I'm understanding it correctly, lengthening the process by O(1) at generation time turns out to be O(x) where x is the non-trivial dictionary they are using since the run time is added to every attempt.

Re:Prevention (1)

AJH16 (940784) | more than 2 years ago | (#38480108)

No, it is O(1) because if you run it twice, it multiplies an O(x) process by O(1) leaving you still with an O(x) process. You were close to correct, but forgot that your brute force started as O(x) so their is no order of computational difficulty gained.

What's a "hardware HSM"? (-1)

Anonymous Coward | about 2 years ago | (#38476040)

And what does the "HSM" in "hardware HSM" stand for?

Is it something that you have to enter a PIN number into?

Re:Prevention (2, Insightful)

Anonymous Coward | about 2 years ago | (#38474470)

My guess is that the passwords were probably hashed, but the general public has no clue whatsoever what a hash is, while they have at least *heard* of encryption before. The email is meant to reassure customers that their password is "safe," rather than being some kind of engineering document on computer security.

Re:Prevention (1)

rasmusneckelmann (840111) | about 2 years ago | (#38475330)

"Encrypted passwords" is just a lay man's term for hashing and salting. I don't think anyone would be silly enough to use encryption for this.

Re:Prevention (0)

Anonymous Coward | about 2 years ago | (#38476578)

I have worked for companies that used relatively weak two-way encryption for passwords. Of course, I put a stop to that.

But yes, people are silly enough to do just that.

Re:Prevention (2)

MBGMorden (803437) | about 2 years ago | (#38477042)

The general public has no idea what hashed and salted even means. In layman's terms, that IS encryption. My bet is that they were indeed hash values, NOT actually encrypted passwords, but sometimes you have to dumb-down the press releases a bit.

Re:Prevention (2)

mariasama16 (1895136) | about 2 years ago | (#38473680)

I got an email last night talking about this breach with links to reset my password and part of that involved setting up their Mobile Authenticator. They also gave everyone a bag of goodies in-game and 3 days of play time (supposed to be for active subscribers, but it appears it have activated my account for 3 days). Much better than the Sony breach where a lot of the affected people were first learning it from the news before they got their notifications.

Re:Prevention (1)

jhoegl (638955) | about 2 years ago | (#38475164)

Agreed, i too was surprised by their accountability and resolution process.
I also liked that they warned users to change passwords elsewhere. It tells me they are concerned for their users.

Re:Prevention (0)

Anonymous Coward | about 2 years ago | (#38476448)

They pretty much have to do this. Once a breach occurs, most states have laws requiring specific actions to be accomplished.

Re:Prevention (1)

lgw (121541) | about 2 years ago | (#38475940)

Why have any customer information in an unencrypted database ever? Why do people still do this? Every bulk store of data of any signifcance to your business should be encrypted, full stop (and the data not of signifcance to your business should be deleted as rapidly as practical).

The trouble is... (1)

rsilvergun (571051) | about 2 years ago | (#38476592)

It was ROT26.

Re:Prevention (0)

Anonymous Coward | more than 2 years ago | (#38494626)

Granted, it could be a simple ROT13 but the mere fact that the passwords were "encrypted" and that the data didn't contain the entire credit card number indicates that the company or somebody inside the company at least put a little bit of effort into securing the data. Unfortunately, securing data is hard and it only takes one oversight to make it vulnerable. The true test will be what the company does now that the breach has occurred.

Keeping data secure is not difficult. Companies *choose* to make data insecure because it makes their job easier when they have to use that data.

I wouldn't say that (1)

Hillview (1113491) | about 2 years ago | (#38473556)

I wouldn't say they're not concerned with security.. but rather, they're probably the most targeted.

Re:I wouldn't say that (1)

you-nix-boy (698814) | about 2 years ago | (#38473744)

All companies are concerned with preventing attacks, but often the business is not interested in investing in security. In my experience, it's always hard to internally "sell" risk, until it becomes a reality and the brand is damaged.

Re:I wouldn't say that (1)

Xest (935314) | more than 2 years ago | (#38480294)

To be honest I don't even think this is the first time for them, which would make this more of a story, but afaik their original leak was never admitted/publicised.

The reason I have my suspicions this wasn't the first time is I signed up to Rift after I'd just created a new e-mail account, I gave up playing after my months trial and hadn't used the e-mail for anything else after either, about 4 months later I started getting spam on that address, and not just any spam, but phishing e-mails aimed at gamers like fake WoW e-mails and such, and originally even a fake Trion e-mail.

It seems unlikely given the address wasn't used elsewhere and that the e-mail was so targetted that this is the first time they've had a data breach, and if that's the case, then I'd argue that they indeed aren't concerned with security. Once is unfortunate, twice is a fucking joke.

Concern? (0)

Anonymous Coward | about 2 years ago | (#38473566)

dates of birth, email addresses, billing addresses, and the first and last four digits and expiration dates of customer credit cards

Why be concerned? That's only everything you need to do serious financial damage. It's not like they stole full credit card information or something.

Sounds like a breach to me (-1)

Anonymous Coward | about 2 years ago | (#38473570)

With a name like Rift they were just asking for one.

Jokes on them! (5, Funny)

Kenja (541830) | about 2 years ago | (#38473596)

That credit card was already stolen and canceled thanks to Sony!

Re:Jokes on them! (0)

Anonymous Coward | more than 2 years ago | (#38479202)

Much of the current Trion team came over from Sony. FYI

They're gaming companies not banks... (2)

mindmaster064 (690036) | about 2 years ago | (#38473600)

They do not have to adhere to the information standards that financial companies do... And, it's probably good.. because some of the smaller gaming companies could never afford it.

My handy reference guide for online gaming:

1) Change all your information to complete and utter BS. Store your BS information somewhere so you can parrot it back if you have to call support.
2) Pay with game cards. If you can pick them up at Walmart even better. But, you can buy codes online.
3) Nothing to lose now... So you don't care if they are hacked.

Just my 2 cents.

Re:They're gaming companies not banks... (0)

Anonymous Coward | about 2 years ago | (#38473732)

"because some of the smaller gaming companies could never afford it."

Utter rubbish, I have secured several sites to PCI compliance level and it only takes me a few days each time, if a company cannot afford to pay a weeks consultancy to a security consultant then they shouldn't be allowed to take credit card payments.

The companies I secured were forced to ensure they were secure from attack by the banks under threat of removal of credit card processing facilities, they were all tiny compared to the likes of a company such as Trion.

This is just shoddy work on behalf of the security and network guys at Trion, lets not try to sugar coat it as anything else, if they were my staff I would fire them and get people in who were prepared to do the job right.

Re:They're gaming companies not banks... (1)

mindmaster064 (690036) | about 2 years ago | (#38473988)

Hacks happen. Every system can and will be hacked no matter what you do theoretically given enough time. You have to have the assumption that it will happen so that the "damage" when it does is minimal. Most of the time when this happens I would say that it does because of zero-day exploit crap on system software. So what exactly are these people doing wrong? That's the problem... probably nothing.. they're as dependent on the coders of their MySQL server as you are on the coders of your OS. You can control your code, but you typically have little to no control of the underlying systems. People don't hack your application they hack on the backend stuff...

Re:They're gaming companies not banks... (1)

Feyshtey (1523799) | about 2 years ago | (#38474406)

I agree with your basic premise. If someone really wants in you're going to lose eventually. But it's worth it to point out that if a hacker is probing your OS or database then half of your security measures have already failed.

It's also worth it to point out that many of the systems everyone assumes are perfectly secure have already been breached. The attackers were just better at the task and no one is aware that it happened yet.

Re:They're gaming companies not banks... (1)

lgw (121541) | about 2 years ago | (#38476008)

If you encrypt all data at rest, you make is significantly harder for an attacker to get anything you'll have to care about.

And any sort of client-server game, especially an MMO, must care about security or it won't survive the waves of client hacks (witness APB, shortest-lived MMO ever). If you're already paying someone to think about security, it's pretty sad not to do the basics for your backend too.

Re:They're gaming companies not banks... (2)

AJH16 (940784) | about 2 years ago | (#38474342)

I have to call bull shit on this. I've worked on a number of corporate networks and can safely say that trying to integrate some of the system's I've seen up to PCI compliance would be virtually impossible without simply using an external service to track the information and then write some other interface to relay the necessary authorizations to the rest of the system, which in many cases runs in to performance issues and/or won't work smoothly (or at all) with existing systems. Perhaps many companies can do it easily, but for many it is a very difficult and expensive process necessarily due to how their systems operate.

That said, I see it as less of an excuse for a software developer as they can write their own systems.

Re:They're gaming companies not banks... (1)

spire3661 (1038968) | about 2 years ago | (#38473766)

If they cant afford a robust and secure customer information database then they have no business taking people's credit cards.

Re:They're gaming companies not banks... (1)

seebs (15766) | about 2 years ago | (#38474530)

Could you point to an example, anywhere of the world, of a "robust and secure" customer information database such that no breach is possible?

Seems to me that if such a thing were possible, surely we'd have heard of it by now.

Re:They're gaming companies not banks... (0)

spire3661 (1038968) | about 2 years ago | (#38475234)

Fuck you and your use of the absolute 'no breach'. A large part of security is loss mitigation, and as such even if there are breaches they are anticipated and contained. There is no such thing as an impenetrable skin, its how you handle the pricks that really count.

Re:They're gaming companies not banks... (1)

Galestar (1473827) | about 2 years ago | (#38474136)

2) Pay with game cards. If you can pick them up at Walmart even better. But, you can buy codes online.

I generally pay with Paypal (commence Paypal is evil etc etc) to avoid having my cc# floating around the interwebs. With Paypal they are not authorized to re-bill (unless you tell Paypal to setup a subscription), and if the servers are compromised, identity thefts can't do all that much with just your email address (assuming you keep your email account secure).

Granted, not as secure as game cards, but just as convenient as entering your cc#, and 100x as secure as THAT.

Re:They're gaming companies not banks... (1)

RedHat Rocky (94208) | about 2 years ago | (#38474220)

"1) Change all your information to complete and utter BS."

+2. I wish companies would give up asking me about my first girlfriend, where I was born and crap like that.

First, if they store these answers, well guess what, when next database gets cracked means bad guys have this info. Of course anyone who knows me or can use google can probably figure this out anyway.

Would be better if each company just asked secret answer 1,2 and 3 instead of personal information I can't change when it gets loose in the world. And gee, I don't know, store each answer in a separate secure database. A guy can dream, no?

Re:They're gaming companies not banks... (1)

antdude (79039) | more than 2 years ago | (#38478452)

Yeah, I always use fake datas for these. Why do they need my real datas? I wished game cards came in bundled as discounts to be cheaper.

Steam (4, Informative)

thesinfulgamer (2537658) | about 2 years ago | (#38473616)

Re:Steam (0)

Anonymous Coward | about 2 years ago | (#38473694)

Duh, it was posted here: []

And that wasn't the first time either: []

Steam is fucked up DRM anyway. Good luck when they decide to shut down your account for some stupid reason and you lose access to everything (possibly losing hundreds or thousands of dollars you used to buy games; weeee!).

Re:Steam (0)

Anonymous Coward | more than 2 years ago | (#38481016)

Because that happens with any motion of regularity. Or wait, it doesn't.

Did you really have to ask? (-1)

Anonymous Coward | about 2 years ago | (#38473736)

" Are game companies not concerned with preventing these attacks?"

Of course not! Nobody seems to care about this shit until something like this happens.

Finally installed a random password generator (1)

Hadlock (143607) | about 2 years ago | (#38473818)

I used to use a "throwaway" password for most sites, that I used for a lot of things. Over the past 10 years I realized that a single password was leaving me vulnerable, so I just started using a password gen plugin [] in chrome and that seems easy enough to use. I don't even bother writing down the password, I figure if I need it again, I'll just use the password recovery down the road.

Re:Finally installed a random password generator (1)

cranky_chemist (1592441) | about 2 years ago | (#38473954)

Obligatory xkcd: []

Re:Finally installed a random password generator (1)

Hadlock (143607) | about 2 years ago | (#38476102)

I'm less interested in remembering a password than I am using the same one for each site. It's been proven that it's far easier to hack a database than it is to crack a password. The less connection there is between my password on (that I never use) and my bank password (that I use weekly), the better.

assuming virtual world identity (2)

circletimessquare (444983) | about 2 years ago | (#38474036)

leads to losing real world identity

literally and figuratively

Re:assuming virtual world identity (1)

Feyshtey (1523799) | about 2 years ago | (#38474224)

They didnt breach the database that contains your Rift character's credit card info and billing address...

Re:assuming virtual world identity (0)

Anonymous Coward | more than 2 years ago | (#38517966)

Maybe if people got a life and went did actual things, this wouldn't be a problem. If this is the best way you people can spend your time, you deserve this.

Attrition. (0)

Anonymous Coward | about 2 years ago | (#38474058)

We'll see how far you get at the next weekly meeting when you mention to your project lead your concerns about security. Your employer has already battled layoffs and the CIO is on vacation. You're behind schedule with your "texture skins" assignment and last week's priority of fixing that model bug that arises when lighting is reduced by 80% is something you need to go back and revise for the sprites your game uses in the 2.5 beta test. But never mind all that... It's pushing 8:00 PM now and after working 60+ hours this week to make the due-date, you're entitled to some time with your family. Fuck, it's Friday. I mean, we're not slaves... The kids are expecting you to see their school play and your wife doesn't want to see you miss another one.

Don't forget to mention to your boss that issue you had with your database security that the "database guy" disregarded last time you e-mailed him about it... Eh, just forget it. That guy knows what he's doing after all, right? RIGHT? Whatever you do, just make sure you fill out a ticket request form for "Reviews and Auditing" because last time you tried to bring this stuff to their attention, you forgot to include a subject and when that happens, the department manager gets a little pissed...

(This is why this shit happens.)

Re:Attrition. (1)

Feyshtey (1523799) | about 2 years ago | (#38474662)

You forgot to mention that the guy that was hired on the database side that really knows security system requirements and finincial data transactions quit 6 months ago because he was sick of dealing with the 60hour a week bullshit and never-ending "crunch time" that is the reality of every game company. He knows that his particular skillset will get him a cush 6 figure gig a block from a beach somewhere that he probably wont even actually have to look for because there are 3 headhunters fighting to represent him.

In the meantime, database guy thats currently responsible for the financial transactions is actually the level 85 geek who was hired at $65k/year to build the character inventory database in the game code. He forgets to pay his own bills on a regular basis due to the sleep deprivation of all-night guild raids, and is completely winging it on the credit card dbase. He keeps telling his boss that they really need a qualified person in this slot, but his boss insists that a dba is a dba, so why should one dba make $65k and another should make $125k? The lack of qualified applicants for for the empty security / financial slot is dumbfounding.

Re:Attrition. (0)

Anonymous Coward | about 2 years ago | (#38475324)

...meanwhile at a board of directors meeting at the Cheesecake Factory...

"Can we change the color of our logo?"

Re:Attrition. (1)

Feyshtey (1523799) | about 2 years ago | (#38476000)

...meanwhile at a board of directors meeting at the Cheesecake Factory...

"Can we change the color of our logo?"

"Absolutely. And we've already hired a consulting company at $700/hour to determine the best possible shade of fuchsia. They estimate it'll take them about 3 weeks."

Obligatory SWTOR comment (-1)

Anonymous Coward | about 2 years ago | (#38474098)

These are not the credit card numbers you are looking for

Sony's Better (0)

Anonymous Coward | about 2 years ago | (#38474356)

With Sony even though the hack was much larger and affected more people and they were slower fixing the problem... They actually did something about it. When my real world information is stolen I want credit monitoring to make sure that I am not going to loose my house, not 3 days of game time and some additional virtual gold. That's just a joke, shame on you Trion.

Re:Sony's Better (1)

Gaygirlie (1657131) | about 2 years ago | (#38474628)

You can't just push all the responsibility on someone else's shoulders when you're also partially to blame. Use a service like Paypal to do your payments and subscriptions on the Internet and that way your credit card details will only ever be on one, single service's database instead of multiple ones; even though the attackers could possibly have gained the account name of my Paypal account they still don't know the password nor a single number on my card and thus they gained absolutely nothing, atleast as long as you're smart enough to use a completely unique password on your Paypal account that you don't use anywhere else.

Re:Sony's Better (0)

Anonymous Coward | more than 2 years ago | (#38480272)

What? Wow?

Troll, someone is walking across your bridge...

Really, that's literally the fifth time this year. (1)

AJH16 (940784) | about 2 years ago | (#38474386)

That is now the fifth time I've had someone manage to fubar and let a DB with my information get out there in the last 6 months or so. I'm literally running out of ways to manipulate my passwords to maintain a unique and secure, but rememberable password. If you just lost my previous password, do you really think I want to have to invalidate the entire approach to passwords I was using and then use one of my more secure techniques with your system (thanks to the even more absurd password requirements) and risk it getting compromised too. Thanks a lot assholes. Glad SWTOR is out now so I can cancel my Rift subscription.

Re:Really, that's literally the fifth time this ye (1)

seebs (15766) | about 2 years ago | (#38474556)

This is why I use software to generate and store passwords. It's a risk, but it's a smaller risk than I would be taking otherwise.

And... TOR's a great game, doubtless, but are you seriously telling us you think EA is going to be more secure?

Re:Really, that's literally the fifth time this ye (1)

AJH16 (940784) | about 2 years ago | (#38474856)

Yes, if only because they have written their authentication system as part of a much larger system to be shared with both a) a store and b) multiple development shops. The amount of effort that in theory should have gone in to their authentication system is much higher, so I would hope it is more securely held as a result.

Re:Really, that's literally the fifth time this ye (1)

Feyshtey (1523799) | about 2 years ago | (#38474828)

If your biggest worry is coming up with a new password and remembering it then frankly, suck it up. You should be changing it every 6months at a minimum anyway. You shouldnt even be using the same password for everything either. They should all be unique. There are a number of free applications that will encrypt and store passords. You can put them in the notes of your smartphone. You can write a bs note to your girlfriend that contains hints to yourself to remind you what the password is and stick it in your wallet or email it to yourself. Worst case if you forget and lose the password(s), almost all companies provide password recovery or reset services.

If you cant be bothered to spend an hour a year helping to protect yourself then your self-righteous indignation at a company that is a primary attack target of sophisticated hacking organizations is a freakin joke.

Re:Really, that's literally the fifth time this ye (1)

AJH16 (940784) | about 2 years ago | (#38474996)

Why exactly should I be changing my password every six months? Does it somehow magically become a pumpkin or mysteriously leak itself? I use a series of several different systems to generate passwords (with different security levels for each system of use) that would not be easily guessed unless you knew the underlying system. This both ensures that passwords are not shared and that it is not easy to compromise other passwords if one is compromised. The main reasons for changing a password every six months are either a) the assumption that it may have been compromised and therefore should be changed, but yet somehow the issue wouldn't still be present allowing the new password to ALSO be compromised or b) the much more justifiable reason, that someone's carelessness (for example writing the password down) may have resulted in an individual password being compromised without a systematic breach.

As I am very careful with my passwords and do not write them down, b is not so much an issue for me, particularly for low security stuff like a video game. Using an app to store a bunch of passwords is both a single point of failure as well as a major headache to actually use for every low priority site that you use. Having a systematic approach to determining unique passwords is far more effective and easy to use. What you are suggesting is that I should compromise my own security by writing down passwords instead of using a system that doesn't permit systematic breakage of my passwords while allowing them to remain in my head.

I am a software developer and a security professional. I take security very seriously when necessary and have a great deal of training on it. While this breach isn't as bad as Sony's it still is a situation that should not occur for a production system. There is no reason why the data should be accessible outside the computer hosting it to anything other than web services (or some similarly secure mechanism) querying in to it via hardened calls that only allow verification of identity and do not allow the information out. It is not hard to implement and I have personally written several systems that do just that. Simply put, the data that was taken should never, under any circumstances be available to a system that connects directly or indirectly to the internet other than through a locked down, single purpose interface. If they were doing this and someone managed to actually exploit that interface or if it was a work of internal abuse, then I'd be willing to cut them a little more slack as those attacks would be harder to protect against.

Re:Really, that's literally the fifth time this ye (1)

Feyshtey (1523799) | about 2 years ago | (#38475944)

If you are indeed a "software developer and security professional", I truly hope that I am not a consumer of the products you build. Many of your statements show a very cavalier (or ignorant) attitude about systems security that borders on negligent. Of course, that kind of attitide might well be at the root of these types of penetrations...

1) From your statements its obvious you're assuming the threat is only external, or only code based, or only protocol driven, etc. A "software developer and security professional" would know better and never think in those terms.
2) A "software developer and security professional" would never refer to an account or database with PII and financials as "low priority".
3) A "software developer and security professional" would understand that just because there is no evidence of penetration and no apparent damage, one must always assume that the systems can and potentially are compromised.
4) A "software developer and security professional" knows that he must assume that more than one set of services by multiple vendors could be compromised. And while guessing a single password might be difficult or nearly impossible, understanding a particular user's "system" is quite possible if you're able to view two or more examples of the outcome of that "system".
5) A "software developer and security professional" would understand full well that hacking database1 might produce no immediate fruit for the hackers. Nor databse2 or 3 or 4. But those 4 breaches combined can be used to create all necessary keys to break accounts on database5, which was the real target all along.

Re:Really, that's literally the fifth time this ye (1)

lgw (121541) | about 2 years ago | (#38476164)

My bank account is successfully protected by a 4-digit PIN that never changes. If you write a system which requires more from your users than remembering a 4-digit unchanging password, you're doing it wrong.

On the backend, encrypt all data at rest, and do your best to detect intrusions, and you'll be doing quite well by today's standards. So few businesses even take those simple steps - it's pathetic, really.

Re:Really, that's literally the fifth time this ye (1)

AJH16 (940784) | about 2 years ago | (#38476688)

I will add two things to that. The system needs to limit unauthorized attempts before locking out, such that it is immune to brute force and the data needs to be internally isolated such that it can only be accessed internally (if absolutely necessary) by two or more individuals both mutually authorizing the access. Take your root of trust, make it as simple as possible, defend it as much as possible and build everything off of that root of trust in as simple and straight forward of a way as humanly possible to prevent exploitable gaps from being introduced.

Re:Really, that's literally the fifth time this ye (1)

AJH16 (940784) | about 2 years ago | (#38476556)

Ok, well I can see you clearly are not a security professional (or not a good one) as your risk assessment doesn't even make sense. I shall respond to each point directly.

1) I did not say anything that would indicate that I do not believe internal threats exist. They account for something like 80% of breaches. For passwords, changing them every six months doesn't help against internal attacks unless the person has left the company and the company failed to notice or notify about the breach. As for my suggested system, it wouldn't just be hardened against external threats, but internal as well.

2) I referred to the password for accessing a game account as low priority. If they are able to compromise the DB itself, my password no good protecting my information and if they are able to break my password and access my account, the most they can do is get information available in public records or buy me more game time. Thus it is a low priority password as a compromise of that password does not cause any direct loss of control of non-public information or any financial loss.

3) Yes, you always assume a system can be compromised, but unless you detect and fix a compromise, there is nothing preventing it from being continually compromised, therefore changing passwords routinely does nothing to counter this. The only exception to this would be if you were to accidentally fix a vulnerability without realizing it or if a company found a vulnerability and fixed it without realizing it had been exploited. In either case, I have no way of determining when/if that occurs and do not feel like the small risk for lower priority passwords justifies the need to write them down and store them externally with a single point of failure.

4) Yes, I do not design my security for low and medium risk sites to withstand a targeted attack. If someone really wants to target me though, there are far more direct ways to go about it. Security is about making it harder to get you than the next guy. A criminal doing a large scale hack isn't going to spend time trying to break my system when they can get tens of thousands of other credentials through automated means. If I had reason to believe it would be worth while to directly target me, I would alter the practice. Also, I consider more than one breach on a password system to invalidate that password system for medium or higher security passwords. That is a big part of the reason for my frustration.

5) Your fifth point is valid, but again, not in the context of an individual user. If someone broke in to 5 systems, without being detected, to try and go after my information, they are pretty damn determined to go after me and the situation is pretty unlikely to occur. (As you were quick to point out, the majority of breaches are internal.) Even if the DBs were simply sold and compiled by another third party, again, a simple, non-trivial system for generating passwords is sufficient to defeat automated tools that would try to find links between the DBs and thus protects against all but determined, targeted attacks.

Please try to think through your arguments and analysis more clearly before you try to lampoon someone's understanding of a topic.

I like how they handle this stuff... (1)

seebs (15766) | about 2 years ago | (#38474488)

Disclaimer: I'm a pretty big RIFT fan. (I post there as the_real_seebs.)

Database compromises happen, and Trion's a newish company that has a lot of customers, and is thus a very good target.

This is the second security problem Trion has ever had, and the only one that made it possible to leak any personal information. (The first was an authentication hole that let you log in to game servers on arbitrary accounts without name or password -- but did not disclose the account name to you.) In each case, they reacted quickly, they announced it, they sent email to people to make sure people who don't watch the site found out, they disclosed what information was compromised, they took steps to correct it...

Now, I know comparing someone favorably to Sony is damning with faint praise, but compare this with Sony's handling of their systems leaking complete credit card numbers and unencrypted passwords.

IMHO, Trion's doing it right. Yeah, it'd be awesome if nothing ever got compromised. But anyone who has the ability to run active services which can be accessed at all, and which cannot be compromised, has clearly made enough money to be able to buy the company and fix it. :)

Re:I like how they handle this stuff... (2)

lgw (121541) | about 2 years ago | (#38476186)

They stored unencypted customer information. That's the opposite of doing it right. Their reaction after the fact was classy, but they failed on the technical side.

Re:I like how they handle this stuff... (1)

seebs (15766) | more than 2 years ago | (#38478854)

Do we actually know that they [b]stored[/b] unencrypted information, or only that attackers were able to extract it in some way?

Except for passwords, customer information [b]must[/b] be at least temporarily in a decrypted form to be used. That means that there exists a way to decrypt it. So if that were compromised, you could get decrypted data even though the [b]storage[/b] was encrypted.

Not saying the storage was encrypted, just pointing out that the extraction of unencrypted data doesn't prove that it was stored unencrypted.

Re:I like how they handle this stuff... (1)

lgw (121541) | more than 2 years ago | (#38504858)

You're right of course, but the bar is lower than you think. Most companies don't even bother to encrypt all data at rest. If they did, then as you point out there'd be a different kind of attack that was common - but that attack is a lot harder, as you need to actually understand the target, not merely get root on one server somewhere in their datacenter.

Punative damages (1)

shoehornjob (1632387) | about 2 years ago | (#38474762)

I'd like to see a law firm launch a class action suit against a company that has failed to take reasonable measures to protect customers data. Hell I'd go so far as to say that it's the best use of a class action lawsuit ever. AFAIK there is no effective legislation that is doing the job. All it takes is one lawsuit to set a precident right? Hell lawyers are supposed to be good at identifying this kind of opportunity so what's the deal? Are they too busy chasing ambulances?

Re:Punative damages (1)

Feyshtey (1523799) | about 2 years ago | (#38474884)

I'd like to see the cost of any serveice that can gaurantee that a breach is not possible.

Sure, they can fund the game for a subscription fee of $15/month.
But the fee to use credit card transactions for the subscription is $40/month.

Re:Punative damages (1)

lgw (121541) | about 2 years ago | (#38476222)

If you believe that "secure" means "a breach cannot happen", you fail to understand security. Companies should be held to the standard of having taken measures to secure customer data that a typical security geek would recommend - the same standard that's used for holding companies responsible for physical security and safety.

Re:Punative damages (1)

shoehornjob (1632387) | more than 2 years ago | (#38480892)

I do't believe anyone here expects customer information to be 100% breach free. Rather I was commenting on how some companies that are entrusted with customer information don't do enough to protect it and are not punished appropriatly when a breach occurs. I see a culture of lax security in this country which (in recent years) has resulted in some spectacular data thefts. I am not in the security business so from a consumer standpoint there does not seem to be enough punitive action to correct this. It is my opinion that several high profile class action lawsuits would send a message that you can't just say you're sorry and give a person a free credit repot for a year to get off the hook. Maybe it is not the best way to approach the issue but it's certainly a start.

Re:Punative damages (1)

lgw (121541) | more than 2 years ago | (#38504910)

Oh, I think high profile class aciton lawsuits are exactly the way to fix the problem. Companies need to see info security as the same level of risk as an unlit parking lot or a safety hazard in the work environment - it's cheaper to have someone who's job it is to prevent such things than it is to pay the lawsuits.

Coin lock? (0)

Anonymous Coward | about 2 years ago | (#38474810)

When you were saying you hoped someone put time into considering database security...Trion did long ago. Given the fact no credit card numbers were extracted, and the info was encrypted (far as we know), then the only thing left is account access. Well Trion Worlds implemented the "coin lock" system about 6+ months ago. Meaning if you login from a different IP address that the last one they saw you come from (yes, even if your ISP changes your address via DHCP)...your game account will get "coin locked" meaning you can't sell or transfer any character items or transfer money out, etc. Seems to me like they pretty well locked it down. Also, I just went to login to Trion to change my password (which everyone should do) and noticed that Trion is FORCING people to change their passwords, secret questions, AND their authenticator codes. Authenticator codes are also required for account management. So it's not like Trion didn't think and do alot of preparation. Determined hackers will always find some way in, it's a matter of motivation, effort and time.

People noticed? (-1)

Anonymous Coward | about 2 years ago | (#38475520)

I wasn't aware that anybody still played RIFT...

I still want to play (1)

jarrettwold2002 (601633) | about 2 years ago | (#38475728)

I still want to play it, I just need a computer with more horsepower. I use a disposable, reloadable credit card for all online purchases. The thing functions just like an ATM card, you can't charge more than what's on it.

I think the positive thing they could do moving forward is explain what steps, in general terms, they've taken to make sure this doesn't happen again. Further, there's no amount of in-game compensation they can give that would mean anything significant.

It sucks, but at least it's been disclosed. How many sites out there, that have your credit card information have experienced breaches and not disclosed it? That's far more scary to me.

Fraudulent Subscriptions -- beware (0)

Anonymous Coward | more than 2 years ago | (#38477770)

I noticed a fraudulent subscription payment when I reconciled my accounts this month. apparently I was charged a subscription fee when I had cancelled my account 6 months back and hadn't been charged since.

I promptly logged on to their site, changed my password and deleted my credit card info. I'd advise that anyone who may have purchased the game (or been forced to provide a card for the beta) delete their information and check their bank statement.

first and last four digits ? (1)

Thanatiel (445743) | more than 2 years ago | (#38482378)

Why the first and last four ?

On the web site, the payment methods only display the last four. Are you telling me they kept the first four "just in case" ?

One could hope they store the last 4 four digits separately, and the full one in a place that can only be written and not read by the web site systems. But then, one could hope the one(s) responsible for this understand the basics of security.

And then again ... first and last four ? How so ?

A) 1234-XXXX-XXXX-5678 ? Waste of space ? Really ?
B) 12345678 ? Then why tell they are the first and last four digits ? Did the thief really needed more information on what he got ?
C) 1234-9999-9999-5678 ? Call me paranoïd but given the "first and last" I can't help but think it's likely.

My subscription is cancelled already and I'm cancelling my credit card right now.

Re:first and last four digits ? (1)

Anguirel (58085) | more than 2 years ago | (#38495784)

Best guess - probably for Customer Service. If you can hack the account website, you can see the last-four (which is there for the customer to know which card is attached to the account). When someone calls in to get an account changed in some fashion, CS can ask for the first-four to verify your identity. They shouldn't have access to password (presumably one-way hashed and salted) or secret question answers (which can be changed via the website anyway), so that won't work for easy ID verification. Dropping the middle 8 means it can't be used for anything else if there's a security breach (like now).

Check for New Comments
Slashdot Login

Need an Account?

Forgot your password?

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>