Monday, June 14, 2010

Current Gaming Security Topics (part 6, End to End Security)


Ok, the plane is getting close to landing and I've typed a ton of blogs (I'll schedule them to post over the next 2 days). This is my last one before hitting the show floor.


Antivirus, Secure Socket Layers, Authentication, Encryption, Memory dumps and so many more problems and technologies to combat them. It's an interesting time in the Security market, authentication companies are being gobbled up by the bigger Security giants out there. As these markets collide we start to see new requests from our customers, "End to End Security". Generally this is the ability to string all of the different security programs and needs together into one package. There are certainly some benefits to this but there can be some pitfalls too.
The benefits are that as an end user I can have a one stop shop for all their perceived security needs. Tokens with Antivirus and Certificates on them. It sounds great. I'd probably look at it, but in the end I'm probably going to go with separate providers.


Hmm as I am writing this I'm trying to figure out my point and how it relates to the online gaming space.


The main thing for me is that I don't want all my eggs in one basket. But do our players really care? As I mentioned in my children security post, I'm pretty sure my kids would go on and play games even if they had to get everything from one provider. I'm also pretty sure that if the technology made it any harder for them (such as having to install software or requiring admin access for it) they would simply move on to the next game. I'm pretty sure this is what we would see from all demographics too. So what does End to End security get us?
I think End to End security is till too new to figure out if our users are ready for it. Our games are trying to have less hurdles to being played and by implementing End to End security we might be defeating ourselves. It still seems like the holy grail, but I think I need to sit back and watch it evolve a bit more before I make any major comments on it.

Current Gaming Security Topics (part 5, Code/IP Protection)


Who can forget the code leaks and rogue servers out there. There were some big ones just last winter. Are we doing everything we can to protect our property? Most of us use card readers to get into our buildings, and tokens to get into our VPN's, what's interesting is that most of the developers out there still only use username and static password to login to our CVS or Codebases.
I've met with a number of smaller developers out there and the impact to them appears to be even greater than the impact to bigger development houses. A rogue server or two out of 10 or 20 certified servers doesn't make that big of an impact, but a rogue server when you only have 1 or 2 certified servers with 100k users could make a huge impact.
The technology has always been the hurdle here. It's usually not that people don't want to use advanced security, it's just that the types of technology used can be cumbersome and may hinder creativity rather than help it. The last thing we want is for a developer to stop using our change server just because it takes to long for him to login to it. As soon as that happens we end up with random bits of code in all kinds of locations that are easily stolen.
Most technology introduced here has been PKI (public key infrastructure). PKI has all been bulky with all kinds of overhead (including servers and servers and servers, oh and the certificates themselves). We have started to see that PKI has advanced quite a bit over the years as it quietly got more and more refined. Today's PKI is a far cry from PKI used in the early 2000's.
Over the last year I started to see a resurgence of PKI being used across markets and honestly it's much more integrated than it has been for years. Most development tools can use certificates for encrypting code natively and most change control applications allow for certificate authentication. With a USB device that means that as long as the developer has the device, he can work more securely without even thinking about it.
While PKI is certainly poised to offer many benefits to source/IP protection, it can still be a costly option. OTP is still an option that can be used for this problem. OTP has it's own technology hurdles in this space too. Most of them have to do with compatibility with the applications that need them. Over the last few months I have certainly seen some of these applications actually start to add OTP options to their products. I can only assume that this is a growing trend too.
For a few years now we have seen a number of hybrid devices on the market that allow for PKI and OTP. The issue in the past has certainly been drivers and operating systems and the quality of the devices (focusing on 2 components instead of just one seems to make certain smaller manufacturers reduce the quality of the devices). As some of the major token providers start to enter this space, we are seeing that the quality of the devices and the software drivers are becoming less of a problem. Along with the quality and software increasing these major manufacturers are bring the cost to implement the hybrid devices down too.
It appears that now is the time to start investigating these solutions and planning for implementations. Gamers shouldn't have to live with rogue servers and publishers shouldn't have to worry about the impact stolen code has on them. Products are ready, so now lets get the developers on board.

 

Current Gaming Security Topics (part 4, Hosting Security)


There are some great hosting company's for online gaming. Some of them take care of everything from the engine to the payment processor to the delivery systems. They are the one stop shop for a publisher to get their game on the internet quickly and efficiently. I have yet to hear of one being hacked. That being said, most publishers are still only authenticate using a standard username and static password.
As we see the adoption of more advanced security in online games we start to forget that it's not just our users that we need to protect. Developers generally use usernames and passwords to access their VPN's, as do most of these hosting facilities. So it's not that far a leap to getting our publishers to use devices to login and perform actions with the hosting providers. Some already have this option available, some are still weighing the benefits.
When I started with VASCO our major market was/is banking. In the US, banking means corporate banking, retail banking is still a little ways off. Most banks utilize application providers for their banking systems (such as Wire Transfers, or Bill Pay, or Payroll, etc.). For our US team it was a natural fit to have the application providers utilize us for their customers, the banks. We see a lot of synergies between these application providers and the online gaming hosting providers.
The major hurdles have been:
  1. Cost

  2. Interest


Cost is always a major hurdle when implementing security. Security is basically seen as, "if I implement it I will probably save money, but I'm not sure how much money". So generally as a cost saving mechanism. Retail gaming has proven that money can be made off marketing on the devices, but generally hosted games do not have the unique market following that the big names do. The cost savings in a space that really doesn't seem to have been hacked yet seems more like insurance than security. There are many cost models that will work here, but if we start to see problems in this part of the market, I expect that security will simply be implemented regardless of the costs.
That brings us to the second major hurdle, interest. There doesn't appear to be many publishers asking for additional security. I think this is because of 2 things, one the publishers haven't been hacked, and two they aren't aware that hackers could be waiting to pounce on them. I've spoken to many of the hosting providers out there and I've heard from just about each of them that they are only asked once in a great while if they have additional security for the players. It appears that the publishers are more interested in protecting their users than protecting themselves. This is great news for the online gaming users, but a potential pitfall for the publishers.
I read a bunch of my fellow security bloggers out there and they appear to be seeing the same trends. It's interesting to think that hackers just haven't made the jump to these platforms yet. They apparently don't read the same blogs I do.
As I am at E3 this week I will continue to build a list of hosting providers that are using advanced security for their publishers and/or gamers and then I'll come back and see if I can make a quick list.

Current Gaming Security Topics (part 3, Payment Protection)


This topic has baffled me since starting in the online gaming industry. Every show I go to I see many Payment application providers. The sheer number of them is staggering to me. Each one I see I try to strike up a conversation and see what they are doing for security or where there maybe a need. What's interesting to me is that most of them do not feel that user authentication needs to be secure for them. Most of them simply allow publishers to use their systems to process the end users credit cards or however the user is paying for the game. This strikes me as what I am seeing in the credit card world too. Basically the processing company simply assumes that if you have the credit card number than you must have the card. At LOGIN I spoke to a payment company and they told me of the problems they face with charge backs and proving that a user is who they say they are. It seems like a big problem for this group, yet they still seem to see user authentication as not interesting.
PayPal is about the only one that seems to embrace user security, well if you don't count the fact that the token devices are hidden deep in their web pages on security. It makes sense to me that if you require the user to make an account, then the user should be using more than a username and password to authenticate themselves.
The issue at hand here is 2 fold from my view.
  1. The users account is used to store the credit card information, if the user goes to view the information most of it is hidden from them and all they can do is to add or change this information.
  2. The customer isn't paying the payment company, or at least not directly. So there really isn't much that is driving the payment company to offer security that may come with a price tag.


I know there is a need here, as I know that I want my payment information protected from prying eyes, but I can't seem to figure out what the business need is and how to make that leap from convenience to security for this part of our market. As I walk around the show floor at E3 this week, I will continue to investigate this space and see if I can find that missing link.

Current Gaming Security Topics (part 2, Revisit Keylogger/Trojan Protection)


Ok it's been a few months and really there has been a lot of new things going on in the online gaming security space. The threat of the Keylogger is still lurking around, but to be honest it hasn't deterred many game publishers from not going forward with One Time Passwords. Apparently the attacks just aren't compromising enough accounts, and the reality is that the attacks really still can't be automated enough. Many users are still only using static passwords and the major game publishers want users to simply move off of this practice on to the next more secure option.


I still have the conversations about the Keylogger attacks verse One Time Password tokens, and it came to me one day, the solution has been staring me in the face for years. So I probably need to do a little research but I think I'm ok with my knowledge here, but if your taking a test on what I'm typing you're probably going to fail, so look it up. I believe that in the late 80's early 90's token devices came on to the scene. I know VASCO started in the early 90's and I know that the first tokens we had on the market were actually PIN PAD (they have a numeric keyboard on the front) style devices. VASCO didn't introduce our Go-1 device (OTP only) until 1999 I believe. So what does this have to do with the attack. Well these PIN PAD style devices were used for what's known as Challenge-Response (CR). That means that the server generates a random number and sends it to the user and then the user simply typed it into the token and the token made a random number based on that. As long as the number the server received back from the user could be matched with the Challenge it originally sent over, then the user would be let in.
The technology hasn't changed too much here, we've added the ability to make the Challenges time based with time based responses (instead of just challenge based responses). But all in all the technology is the same. It was designed to stop shoulder surfing (remember my disclaimer about my facts up above) attacks. If an attacker is watching the user generate the password and type into the screen, the attacker would need to get the same challenge generated and sent to them during the same time period in order for the password they stole to work. So this pretty much completely defeats keylogger/shoulder surfing attacks.
The major hurdles for adoption of this technology really depends on what we believe our users will do. The original hurdle for OTP devices was that we didn't think users would want to hold the devices and might leave us for the next game. What we found was exactly opposite. Not only did users not have a problem with generating a password and typing it in, but the devices sold out in record time and were becoming collectable.
With Challenge Response we need to ask the user to take the next step. Not only do they need to turn the device on, but they also need to type in something they see on the screen before getting a password from the device. While I believe the time it takes for someone to do this is probably less than a few seconds, it's still something that hasn't been introduced to our users yet and it's different than what they are doing at work (where they probably only use an OTP only token).
The benefits here seem to outweigh the usability problems. First we solve the keylogger problem and the marketing real-estate on the device is much bigger than the single button ones. What if we make It so that we extend the in game feeling right to the device by making the challenge from in game languages and character sets. We can start to push the game further out to the user's own environment while making them more secure in the process.

Current Gaming Security Topics (part 1, Child Security Thoughts)


Ok seat back, stuffed in this plane, ready to put some thoughts together.



So as I mentioned in my last post the main trends I have seen in the Online Gaming market have been (I've added):

  • Child Protection (My post below)
  • Keylogger/Trojan Protection (I wrote about this one a few weeks ago, I need to revisit this I think)
  • Payment Protection
  • Hosted Security Options
  • Code/IP Protection
  • End to End Security


I'll refine that list as I pull my thoughts together.



Let's start with the one that is closest to my heart, child protection. So I have 4 children that range in age from 16 to 4, which means I have many walks of life in the gaming space. My oldest is all about Facebook and other social gaming apps (Farmville, etc.). My 11 year old is all about pushing his boundaries, so he wants to play WoW and is dying to get on Facebook , but I've managed to sway him to stay on Wizard101, FreeRealms and FTP Flash Games for a little longer. My 6 year old is all about whatever the 11 year old is doing...but...WoW and Facebook appear to be out of his comprehension at this point, so he has stayed pretty much on Wizard101, Club Penguin and <insert web based gaming>. My youngest is content with watching her older brother run a character named for her through Wizard101 collecting pets and telling him where to move the little computer girl around the screen.

So the landscape of security risks for them are all over the place for me on a personal level. On a technical level, so far I don't even think one of them has thought about security at all yet. I sat my 11 year old down to chat about security on Facebook as he is just about ready to make the leap. I explained all about the "bad" people out there. His comment "Ok Dad, can I just set one up now?" I kinda expected that but the thought of him on Facebook is scary, I mean the 16 year old almost shocks me on a daily basis as I find out more through Facebook about her than I do when I chat with her. So for me security has to be introduced and I'm making a big push for it everywhere.

Since I work for the largest Token Manufacturer in the world (30 different hardware models alone now), it's hard not to let the kids play with them. My WoW account is protected by one and I must have a couple dozen hanging around with different logos that they have picked up and asked me how to use it. It's really my WoW account that really pointed me to what I thought should be investigated. I avoided having my account hacked and got the Authenticator on it as soon as they were ready. This stopped my kids from being able to login to move my character around (and get him killed). As long as I had my keys on me they were stuck. Then came the weekends, and since I am not a morning person, they would have the keys and off and running on my WoW running up my repair build. What I found interesting was exactly who was using the account now. I assumed it would be oldest boy (the 11 year old) but instead it was the 6 year old. He found it easier for himself to login, because he "didn't need to remember which keys were the password ones". Well this isn't really security but it sure sold me on the devices for children.

As far as the security goes, my account still hasn't been hacked and I still end up with new level 1 characters created in my account every few weekends. What I noticed on their Wizard101 accounts, is they have their passwords written down on scraps of paper everywhere, and not just once, there have be 3 or 4 scraps of paper with the password and username laying around my computer room. What shocked me even more was they were sharing it with our neighbors so that they could help them play (I stopped this activity pretty quickly I think). Additionally if my 6 year old left the desktop computer to play on the laptop he always needed my help, either to type in the username or to help remind him what keys he needed to press. I attempted an experiment and changed his password once, and the effect was pretty much the same. He just asked me to write it on more scraps of paper. The concept of security seems to be lost on children under 10. If it stops them from playing a game they will move on to the next game.

And what about the "bad" people. In the Industry I have been having lots of discussions about using a token to prove that the user is a child. It is an interesting concept. Basically if we put it in a store and ask the potential user to come into the store and buy the device we expect that we will get less people that will pretend to be children. It seems logical as I would imagine people might be more hesitant to walk into a store and buy a token that is labeled and packaged with kids toys. I do imagine that if a person wants to attack a child then this will probably be less of a hurdle for them, but it removes the anonymity of the user too and captures them on store surveillance video as they are purchasing the item.

So I think the last point of concern is the FTP (free to play) and social games. There are security issues here that are similar to the other games but for children the accounts appear to be too liquid (they create new ones every time they forget their passwords). As my company starts to roll out new security options soon I suspect that these types of games will have new options to embrace. As business goes I think these new technologies will help usher in a different type of thinking. No longer will it be the cost of doing security, instead it might be the cost of not doing security. I'll write up more on this technology at a later time.




 

Monday, April 5, 2010

I was writing my blog and I was struggling with the name of token.  I mean every day I say DIGIPASS or token, but I realized that most of my readers have no idea what a DIGIPASS is (unless they have talked to me).  So I started calling them Authenticator's.  Everyone in the gaming space knows this name now, thanks to Blizzard.  But I still get the random person that only knows the token device as an RSA SecurID (…"that we used way back in the day at some obscure high security government job…" I love those stories).  So I thought I'd put together a quick post on all of the names I have heard so far for one of these simple little devices:


·         Token (I remember when I first started at VASCO and people thought I was talking about token ring networks).
·         One Time Password device
·         Password Generation Device
·         VASCO DIGIPASS
·         RSA SecurID
·         Security Token
·         Security Dongle (shouldn't this be something you plug into your pc?)
·         Security FOB (or just FOB, which sounds like you have something stuck in your throat)
·         Two-factor Authentication Device
·         Blizzard Authenticator
·         ….and probably more...

Me personally, I'll probably stick with Authenticator or token or DIGIPASS (if you're a customer). I remember getting the email with the logo for the new Blizzard "Authenticators" (internally we were pushing for "Security Assistant", Authenticator is so much sexier, hence why I am not in marketing…lol). So pretty much after that day, they will always be known as Authenticators to me.

New titles and security thoughts

So recently I have been working with a number of developers that are getting ready to release titles.  Interestingly enough, most of these clients are now thinking about Account security before they send the game out to publishing.  This should be recognized as a huge shift in the gaming world.  Security was something we used to think about as an after thought, it's nice to see that people are starting to include security as a forethought.

So most online games are looking at some type of account security, be it hardware or mobile security or a combination of both.  The main thing most of these developers are looking at is how do I roll out the security and when?

As a security person, my first reaction is right away and before the user can even start playing the game.  So let's evaluate this.  If we give users the option to choose security or to start playing the game, most users, including me, are probably just going to start playing the game.  Then if I like the game or start to really invest some time or money into the game, I will take a harder look at my security.  The problem is that most users will never come back and take that second look at their security unless we force them or something bad happens.  And if we end up having something bad happen to the user, it costs us money and if we force the user to do something then we might lose them (which costs us money).

 So if we start right at the beginning with stronger authentication then the users will not have to think about it later.  Great, but what is the beginning?  Is it when the user picks up the box on the store shelf?  How about when the user registers for their account?  What about when the user registers to play a beta account and we allow them to transfer it over to a standard account?  For me the beginning is when the user has created their online account, be a forum user, an game account, or whatever the account is that is created for the game.  This is the point at which we need stronger authentication.

 So if the user registers for an account, do I ship them an Authenticator before I let them play (or pay)?  Well this is the next biggest question I get, "How do we get the devices to the user?".    There are a few schools of thought here. 

 First one is generally perpetuated by our users, "Put the device in the box".   Great thinking, but its not that easy as I'm sure we are all aware.  Our margins on the box and the materials in the box are very slim and putting anything new in the box could be very costly.  It is an interesting idea from the security perspective provided that we force the users to use the device, and we could even tie the serial of the game to the device in the box (great for IP protection or stopping account sharing).  Another problem with this is that we are seeing a huge rise in digital distribution. I read an article today that digital distribution will top 3 billion dollars and is expected to increase.  So it would appear that our users are moving more towards this method rather than our boxes and in this case we probably wont have many users getting the security devices we wanted them to have in the first place.

 The second one is a bit more interesting, which is to force the user to install a temporary software application on their mobile device.  This certainly gets around the cost problem in the box, but now we have to hope that all users have a mobile phone.  This doesn’t really work very well for our younger users.  But if we are marketing for the older crowd anyways, this is no longer a problem (or at least much less of a problem).  With digital distribution this certainly is a much more viable solution.  The main issues that you have here, is that it is generally more cumbersome for users to start using the game.  Then once they are in and using it, we have to worry about the security of their mobile devices and other issues around that (we'll talk about the security issues in some other post).

 So how about some new solutions?
·        What if we simply sold the authenticator at the store on it's own.  Like our pre-paid game cards (or as a replacement to them)?  Purchase the device and you get X credits, oh and by the way you need the number from the device to login to use the credits.
·        What if we text them passwords until they get their devices.  Ties the user to a mobile number, user doesn’t need to install any thing on the mobile device, and we are shipping them their hardware device while they start playing.

 I'm always interested in new ideas, I think I saw a new technology company out there that was putting security on SIM chips for phones.  VASCO has done this for a while, but this new company is making a sticker like device that goes over the SIM and offers additional functionality.  What if we were to use something like that (I would think people would start breaking their phones pretty quickly and then we would become phone repair gaming companies).  It's an interesting idea.

Tuesday, March 30, 2010

Blog titles gone wrong.

As I was working on figuring out what to call my blog I went through a bunch of names. I started with Gaming Security Notes, everyone thought it was dry (including myself). I spoke to a close friend of mine that I haven't seen in forever, she was a guild mate in Everquest in a guild I ran back then. She suggested Iweil Says…, I liked this one, but I'm sure no one would ever know what it meant unless you talked to me about my life as an online gamer (my in game name was randomly chosen in EQ as Iweil, I have used it ever since for all of my MMO's). Finally my technical team here in Westborough came up with "…And things like that", in honor of my infamous wow.com interview.

If you haven't read the interview, your head will thank you later. It wasn’t one of my finest performances. 2 days on the floor at BlizzCon, caught right before an Ozzy show, it was pretty much the best I could muster. At the end of pretty much every line I added the quote "and stuff like that". I think Wow.com finally cleaned up the interview a little bit, as I just re-read it and it's not half as bad as I remember it. Either way, most people I know will never let me live this down, and to tell you the truth I'm not sure I want to.

Either way, My blog links are:

http://andthingslikethat.wordpress.com/
http://iweilsays.blogspot.com/

Hopefully they will have the same stories on both…but…we never know.

Friday, March 26, 2010

What's the use of One Time Passwords?!?


Hi again, so we've all been reading things about One Time Password's and how there is a real attack that makes One Time Passwords useless. Well "useless" might be a bit of strong word, but I'm sure that's what our players are thinking. I know I'm a little late to the game here and a bunch of my colleagues have done posts and have even had some talks on the issue. I'm going to try to gather this all up and add my own observations, so…….let's take a second to discuss what's going on and what we should be doing about all of this.
 
First let's look at a One Time Password…what is it? Why do we even use them? Are they secure? What can I do to break them?

One Time Passwords (OTP)…this is a technology that can be used to make a password that can only be used once and changes in-between uses. Most of the time people see this technology on hardware devices like the Digipass tokens…but this isn't the only way an OTP can be delivered. Some of the other ways are via SMS or as an Application on a PC or a Mobile phone or pretty much anything. The main reason to use the hardware devices rather than other locations is simply that the hardware device is a secure platform that is generally tamper-proof or at least tamper-evident. This makes it hard for hackers to get at the only thing that actually matters off the device, the seed.
  
So I wasn't going to get all the way down into who the technology works but as I'm writing this I'm thinking that I might as well since I'm here, then it will be here for everyone to see and refer to.
  
So basically the technology is a random number generator. It uses a few items to create the display that you see. There are a few ways to generate that random number but most of them work along the lines of combining some type of counter (like every time the button is pressed or every x amount of time passes) with some random number (we call this the seed) into some algorithm (I like the open standard ones like 3DES or AES so that you don't have to worry about the security of the algorithm). So in order to generate the same OTP, you need all 3 of these components FOR EVERY DEVICE (this is an important point, people forget that even if you get all the components for one device, the seed and probably the counter are different for the very next device).
  
With that out of the way, now let's look at why I'd use an OTP. Mainly I use an OTP because I hate changing my password. Most sites now make users change their passwords every X days, but I know I haven't changed my Station account password in like 11 years. And when my bank finally made me change my online banking account password I ended up getting myself locked out because I couldn't remember what I changed it to.
  
So am I suggesting that you get rid of your static password? No. In fact Static Passwords have their place in the security world and probably will for a long time to come. Why? Well it's all about the factors of authentication. Let's think about it this way, if I leave my token on my desk and there is a piece of mail on my table that sales Will LaSala, I think most people would be able to figure out my user name and if they have stolen my token they can login as me pretty quickly. If I combine this with a static password then they would also need to have that to login as me, and if I use a finger print to get in, now they need that too. The more factors we add the more secure we are, but the less convenient it will be for me to play, which means the less likely I will play which means I won't be paying for that subscription for much longer. Oh and the more factors we add the more we have to pay as a company to get the product in, and if someone manages to cut my finger off and guess my password and steal my token, the higher the cost for me to fix the problem. So security is always this balance of Ease of Use, Cost and Security. Ok enough preaching….
  
So what do we use OTP to fight against? Well this is pretty easy when you think about it. The main problem before OTP was that people would use the same static password for everything. So when I signed up for my Battle.net account and then went and signed up for my mmorpg.com account, typically users would use the same username and password. Well if that web site was some bad site they could steal my password and then just login and steal my account. By requiring the OTP we can be sure that even if I use the same username and password at these sites, the token will only work on my Battle.net account so I'm pretty secure against attacks.
  
The statement I get when I use this story is, "well what if I want to use the same token for another site, it would make my life so much easier". You're right, but then we run into the problem that basically your secret seed value can be shared among different services and potentially hacked. Some day OTP devices will be shared across providers and we will trust the providers that are doing the sharing and that these providers will protect those credentials from the bad guys attempting to steal them. But today there's just too much risk for my liking.
  
Now we also use OTP's to fight against social engineering attacks, attacks where people call up and ask you your username, password and the OTP over the phone (yeah why would anyone do this, I don't know but It happens every day). We can train people not to read the OTP over the phone, remember the disclaimers that everyone uses "We will never ask you for your passwords". This is the same thing as it is for static passwords and OTP's.
  
Great silver bullet right….ok so we all know this isn't it. It helps restrict the attacks and helps push our attackers on to the next "lowest hanging fruit", it buys us time to figure out what to do next. How much time you get really depends on who you are and how tasty your fruit is.
  
So let's discuss the latest public attack against OTP which happened to one of the big publishers over the last couple weeks.
  
Ok so I'm not going to make any ground breaking announcements I don't think, but let's review.
  
What happen? Well most people say it's a Man-in-the-middle attack. This is untrue. A Man-in-the-middle attack is when someone hijacks a session and changes information in real-time for their own benefit. The reports on what this attack actually was are a little less scary. Basically it was a Trojan that installs a key logger that waited for the game client to launch and then started recording key strokes and sending them to the attacker. As long as the attacker turned around and used the credentials immediately then the attacker could get in. I can already hear the responses, "That's a Man-in-the-middle attack"…no its actually closer to a shoulder surfing attack (basically where the attacker walks up behind you and reads the static password your typing in and the OTP that was generated and then shuts your computer off and runs over to his and logs in as you).
  
So why didn't OTP fix this problem? Well as I mentioned, it's basically like they were looking over your shoulder and shutting off your PC before you were ever able to login with that OTP. If you had managed to get in with that OTP or the next OTP before the attacker could login, then the attack wouldn't work. OTP's are great when the attacker can't do things very quickly or can't gain direct access to the end-user in some way. They were perfect against the original problem of passwords that could be stolen and saved for later use. OTP's have a shelf life that is relatively short. If you don't use the OTP before the next counter then you won't be able to use the OTP at all (you'll have to generate a new one).
  
So what do we do now? First remember that attackers go after the lowest fruit or the tastiest fruit first. So if you application is still only using static passwords, fix this first. This is easy and OTP's are relatively inexpensive, accepted by users and solve this problem. Second if you have an app where people will stop at nothing to get access to it, start planning for your next 3 steps in security. Realize that each hurdle you put in place will buy you time until the attackers adapt.
  
As I mentioned I'm still a fan of OTP. OTP is good when it's combined with other security related technology. So proper antivirus software, malware detection software, even software on the server that detects what IP you are logging in from would have helped to prevent these attacks. If we educate our users and implement secure practices, OTP is still a very good option for security.
  
If we assume that we can't stop these attacks with other technology what can we do? Well there are still a few OTP options available and I'm sure we will see some of these soon. Here are some of my thoughts:
  1. How about if we ask for 2 one time passwords. Maybe one when we launch the client that gets validated locally and then how about a second one when the network connection is up. Using the same device, this means that the attacker would need to steal some local information from the client so that it can validate the OTP locally and then of course it would need a key logger to get the network on too.
  2. What about using 2 OTP's at different points. How about we use an OTP to login to our account, and then whenever we notice the user is doing something potentially dangerous, we ask them for a second OTP. So if the user is deleting or selling their gear, or simply transferring large amounts of currency, or if they are trying to change important end user data, like an email address.
  3. Session Based (or mutual) OTP, generate an OTP on the server and send it to the client to type into the device which will unlock the device and then generate an OTP that can be typed back into the client and sent to the server for verification.

  4. Sign details the user would know. This is an old trick called transaction data signing, basically we take a few pieces of data and create a unique signature for them. The signature can be validated on the server and we can ensure that none of the data has changed from the client to the server. I'm not really sure what to suggest to sign here, but some of my thoughts are:
    1. Serial Numbers
    2. Account Numbers
    3. Item IDs, or other in game numbers that users would know and understand
    The main thing here is to make sure the user understands what they are doing and why they are signing the data. So if we use random data it is no different than option number 3 above.

     
    Those are just a few of my thoughts on what we should be looking at to add security to games that already have OTP's in place. I'm sure there are other ones that we can come up with, and I would love to hear them so leave me a comment below.

     
    As a first post, this one is extremely long…sorry about that, I'll try to keep them shorter next week.

     
    Thanks for reading this far :)

    -Will

Thursday, March 25, 2010

Welcome to Gaming Security ..And Things Like That


So welcome to my blog. I've been asked a few times to create one, but to be honest, I just never thought I would have the time. Over the last few weeks there have been a few things going on in my industry that finally got me to the point of actually wanting to write things down.

So first things first, I work for VASCO Data Security, INC. This blog does not reflect the views of VASCO, and it is not actually affiliated with VASCO in any way. I'm not here to try to sell you on security or to tell you how VASCO can make your life better. I'm hopefully here to add information on what I see as being an industry professional working in the gaming space.

Here's a quick rundown on what I think I'm going to be writing about:

  • General Security Concepts
  • Interesting Security Threats
  • Security Technology (Past, Present and Future)
And whatever else seems to fit in those areas. (I maintain that I am very scatter brained and my mind wanders so you could end up with a little bit of everything if this goes well)

I play games, I've played games for years. I've beta tested more games and software programs than I have fingers and toes. I can read and write code, but I have never done it for a 3d game. I have done it for web site and flash games and other things like that. I have worked in the online industry since 1992 (yeah that's not that long ago, but I still remember my first MUD). I live and breath online security today for all kinds of applications. This blog will hopefully be a collection of notes on the my experiences and a working space for discussions around those experiences.

I guess I'll fill in my bio soon too as I'm sure it will help everyone understand more about my mindset and where I come from. Needless to say, just because I've been doing this for a while doesn't mean that everything I say or do is law. So please leave me comments and let's have an open discussion. If you don't like the way I describe something and think you can do it better, great let's hear it. I work and play better when people talk to me. So let's see if we can get a lively bunch of readers and really add some interest to the security world.

I'll post my first real write up shortly and then we can see where we go from there.

-Will