Monday, June 14, 2010

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.

No comments:

Post a Comment