keep me logged in, durnit!

Published July 28, 2006
Advertisement
Thanks for the info on the whole 'keep me logged in' thing. It pretty-much confirmed my suspicions about how that whole checkbox worked. What I'll be storing as a 'keep me logged in' will be the user's user number (which never changes) and a double-hash of the username and password.

Gotta go with a double-hash on the password because I'm not storing your password on the server. When you enter your password in the account-o-matic machine, it sends the password (encrypted) to the server, which then decrypts the password, hashes it, and stores that hash in the database. That way nobody (even me) will know your password.

Of course, that means that I can't just concatonate the stuff together and store a hash locally. . .

"flyman-flymanspassword" -> hash -> 1233443

Because I need the ability to recreate that hash on the server-side, and I can't do that without knowing the password, and I don't.

So it'll work more like this. You enter your username and password.

"flymanspassword" -> hash -> 32232
"flyman-32232" -> hash -> 1235334

And since I already have that first hash stored on the server (32232), I have enough information to make "flyman-32232" on the server side, so I can then construct 1235334, compare the values, and verify that you are who you are.

Pardon me if this is already obvious, but I did need to talk it through.

This does give me the following strong security. . .

- The passwords stored on the server are strongly secure, as they can't be taken from a hash back to a password. The best you could do would be to find a password that resolves to the same hash, and as long as you're into the realm of brute-force, I'm happy.

- The user-password data stored on the client as a cookie is strongly secure and can't be disassembled from the hash back to username and password-hash, so someone reading your cookie files won't be able to get your password without doing two levels of brute force, so I'm twice as happy.

And the following weak security. . .

- Copying cookies will allow others to log in under your account.

- A reversable encryption is used to send the password to the server for hashing. This could be solved by letting the applet make the hash, but that'd be an even bigger security concern given how easy it is to disassemble Flash.

A couple of folks did point out things that I could do to make the security stronger, like IP checking or storing machine/MAC serials, but we're then getting well out of the range of what security is needed for some simple games. IP Checking really creates more problems than it solves given stuff like dialup accounts and IP-sharing routers. And I don't wanna start yelling at the user if he updates his machine.

. . .that's Microsoft's job :)


I wasn't too worried about someone stealing a cookie to post Pop Pies scores as another user. My real worry was that I'd have some dumb user who uses the same username and password everywhere on the internet. Without some kind of hashing mechanism, someone browsing his machine could copy my cookie data, decrypt it back to a username and password, log into Amazon using that information, and buy a bunch of stuff. This does fix that problem strongly, so I'm happy with that.

I just wanted to be as good as gamedev or digg. And this will be at least that good.
0 likes 0 comments

Comments

Nobody has left a comment. You can be the first!
You must log in to join the conversation.
Don't have a GameDev.net account? Sign up!
Advertisement