2
\$\begingroup\$

I'm trying to find a solid architecture for authenticating users against a database. I have a game client, which I plan to serve up a request with. The transport doesn't really matter, but at this point I'm thinking HTTP and leveraging either SSL or WS-Security to ensure the encryption of data over the wire.

I'd like to avoid middle-man attacks if possible so I'm leaning towards WS-Security even though I know it costs more in terms of overhead.

On the service side, I'd like to use an authentication framework such as Apache Shiro to authenticate users against a MySQL database. I'm not sure if I can leverage the session features or not, as I haven't looked that for into it, but it'd be great if I could.

It will probably be a mix of storing some session information in the database and if I can leverage Shiro's session features then that's a bonus.

My real question is about the handshake between the client and server. If I use WS-Security isn't all that taken care of for me? Does that alone make the overhead worth it?

If not, what should I do here? I want to make sure all of the requests from the client are authenticated but I also don't want to have to jump through hoops to make it happen. Would something as simple as HTTP digest authentication work here?

One constraint I have is access to libraries. If it's not free and can't be used in a commercial product then I can't leverage it. My client is going to be written in C++ and I can use whatever language makes it easiest (I'm leaning towards Java) to make it happen on the server side.

I plan on adding support for users to purchase in-game items through micropayments down the road, so this handshake mechanism definitely needs to be secure.

I keep hearing people suggest REST + SSL, and to examine Amazon's Signing and Authenticating REST Requests page. Is that a viable alternative? If I used that and something like Apache Shiro would I have a winner?

\$\endgroup\$
1
  • \$\begingroup\$ @downvoter - can you provide a legitimate reason for downvoting? Clearly research has been done and the OP has come with some very well posed problems. \$\endgroup\$ Commented Jan 20, 2012 at 8:54

1 Answer 1

Reset to default
1
\$\begingroup\$

SSL is not vulnerable to MITM, unless the client machine has malicious root CA certificates installed (in which case you can't do anything at all as you might as well assume that the entire client is compromised). If you get a certificate from a proper CA like Verisign you will be assured that any communications with your server will be secure (except in academic situations like quantum computing). If you use an encrypted channel during the authentication phase you can use whatever serialization/communication paradigm you want (REST, Protobuf, etc.).

In other words all you need to do at the end of the day is make sure that the passwords are salted and hashed in your DB, preferably double-salted so that your client 'remember password' functionality can store a salted hash on the hard-drive; instead of a clear-text password.

Alternatively you could look into:

  • SRP which doesn't need to occur over a secure medium.
  • Mutually-authenticated TLS/SSL (using a client certificate). The nice thing with this is that it enables offline (LAN) scenarios as clients can authenticate with each-other without the presence of your authentication server.

WS-Security is primarily geared toward federated services, i.e. cross-enterprise, (as are most of the WS-I extensions) - which is probably not a concern for you. At any rate the WS-Security has the associated overhead of SOAP (and the underlying frameworks/marshalling needed to handle SOAP calls). SOAP is a very heavy protocol and is probably an very poor choice for game development. I would avoid this entirely.

\$\endgroup\$
5
  • \$\begingroup\$ Thanks for the response Jonathan, the information you provided me with was very helpful. I do have a few follow up questions though, if you don't mind. SRP sounds like a great method of providing user authentication, however if I'm passing sensitive data over the wire I would still need something like SSL to make sure the message's data is encrypted correct? That's a primary concern here. Also, once I've authenticated against the server, I still need to authenticate against the backend of my game and establish a session. Would using an API like apache shiro work for this? \$\endgroup\$ Commented Jan 19, 2012 at 13:19
  • \$\begingroup\$ @ZacharyCarter unfortunately I can't comment on Shiro because I have never used it. It sounds like you really should use SSL (but remember, only when you need it) - however SRP has a pretty neat side-effect; both parties will have a shared (and secret) symmetric encryption key which you can use with something like AES. A hashed password is by far the simplest solution - and if you send it over SSL/TLS it's as secure as it gets; simplicity can be just as secure (if not more) than complicated solutions. In regard to your last question: do you control the physical wires between the servers? \$\endgroup\$ Commented Jan 19, 2012 at 14:00
  • \$\begingroup\$ @JonathanDickson Okay so I'd be sending any sensitive data I need to exchange between the client / server (including initial credentials for authentication prior to session establishment) uing SSL. Once I've done that, don't I also need to authenticate the user credentials against the database, since that's where the credentials for the user account are stored? That's where I'm thinking of leveraging a library like Shiro. I won't own the physical wires, it will be a client connecting from their desktop PC to this service layer. \$\endgroup\$ Commented Jan 19, 2012 at 15:26
  • \$\begingroup\$ Okay so I think all of this is starting to make sense to me. In terms of securing data over the wire and ensuring a proper client / server handshake I leverage SSL. To authenticate against the DB / establish a session I can use a library such as Shiro. What about CAS how can I limit certain parts of my API to certain users? Authorize against the DB? \$\endgroup\$ Commented Jan 19, 2012 at 15:33
  • \$\begingroup\$ @ZacharyCarter exactly, when you do the authentication against the DB just grab which roles the user belongs to - then just check that list (preferably a hash-coded set for speed) each time the user wants to perform an privileged operation. \$\endgroup\$ Commented Jan 20, 2012 at 8:18

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.