Jump to content
  • Advertisement
  • entries
  • comments
  • views

Security cookie question

Sign in to follow this  


Okay, I know I can probably get a longwinded answer if I look elsewhere, but my question for today is. . .

How can any kind of reasonable security and the 'keep me logged in on this computer' checkbox be compatible?

You've seen it everywhere, but let's take gamedev as an example. You create your account with your name and password and such. Then you log into the site. And if you're like me you also click that "keep me logged in on this computer" checkbox so that you don't have to futz around with passwords again.

This is, obviously, done with a browser cookie that stores enough information to get you logged in. The question is, how can this be done in a manner that's even somewhat secure? The simplest solution, storing the name and password as plaintext in the cookie, is obviously flawed. However, even if I mashed the username and password together and did some kind of hash that I could then compare against a similar hash on the server, all that does is prevent someone from retrieving the username and password by reading the cookie -- it doesn't prevent someone from duplicating the cookie on another machine and logging in.

Is this just a necessary evil of the 'keep me logged in on this computer' checkbox, or is there something I'm missing.

I'm just wondering this because my games will work similarly to that. You'll create your account, then the first time you start a daily puzzle, it'll ask for your username and password. You'll then have a checkbox just like that, and if you check it you'll be automatically logged in for any games you play on the machine, and it'll be done by exactly the same method that the games currently remember your name and volume settings - by Flash Shared Objects (aka Flash Cookies). Flash Cookies are very similar to standard browser cookies (search your hard drive for .SOL files and you'll find 'em), and they're about as easy to read with simple freeware tools.

So I figured I'd stand on the shoulders of giants and ask what's the method to store a secure 'keep me logged in on this computer' cookie.

And if there ain't one, as appears to be the case, say "there ain't one".
Sign in to follow this  


Recommended Comments

The best way I can think of doing it would be to store the username (or a userID number) in a cookie, along with some kind of GUID (not in any way relevant to the password). If these match, the user is auto logged in.

If you feel the "stolen cookie" scenario is a problem (which I don't think it is, really), you could have the GUID change every login. This leaves a limited time frame for using that GUID (until the next login). If you require the password to change to a new one (which you should, since the duplicator doesn't know it in any case), then the real user will just fail to login, which would require his user&pass, and then invalidate the last GUID the duplicator has and give the real user a valid GUID.

This would limit any damage a duplicator could inflict to one login. Can't think of a much better solution than that :).

Share this comment

Link to comment
How about you use the person's IP address (and possibly MAC address) in the hash key generation? This would prevent people from copying cookies around to get by security.

Of course, people would have to relog whenever they got a new dynamic IP, but that seems a small price to pay for extra security.

Share this comment

Link to comment
There ain't one.

At the end of the day, any kind of automatic logic can be used to gain unauthorized access, in some way or another. That's the risk that the user takes when using that option. If you're deeply concerned, place a warning on the option describing the fact that it is effectively making it possible for Anyone Who Wants to get into the person's account if their local machine is compromised (or, more likely, in a shared/public setup).

Other than that, it's not really worth the effort of doing more than a salted-hash on the username/password, recording the user ID number, and sticking that in the cookie. A determined cracker will breach security if they're in a position to read arbitrary files off the machine in question, so any time spent trying to deter them has severely diminishing returns.

IMHO, security tends to have a breaking-off point where it ceases being worth any effort; that point is just past the maximum patience level of newbie script kiddies who are incompetent but dangerous. If you can make them get bored and give up, you win; a salted-hash cookie would accomplish this. You'd be surprised how far a simple ruse like s/userhash/scorelist can be - script kiddies won't think too hard about it and will overlook the simple word swap. Naturally this will do nothing but make a serious attacker chuckle at your puny efforts, but a good attacker is going to find everything puny.

Share this comment

Link to comment
My first thought was, like Jesse, to just use an IP or MAC address (or some other arbitrary machine-specific identifier) to create the hash. This should prevent any simple attacks. But really, if someone wants the Pop Pies high score that bad, let 'em have it dude [smile].

Share this comment

Link to comment

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
  • Advertisement

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

GameDev.net is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!