0

I have a flash game with a php backend and MySQL database.

To play the game, users must login. During gameplay the client will also periodically send updates to the database. For example, when the user purchases a new in-game item.

I have two concerns. Firstly the username and password are being sent in plain text to the server (it's encrypted in my database however). Secondly, after logging in, the client will be sent a user ID to be used in all subsequent requests. These requests are also being sent in plain text.

Both of these communications are at risk from packet sniffing. Once someone gets an idea of the structure of the requests to the server, they could create their own bogus requests, substitute their own values/user IDs and generally cause a lot of upset.

What are my options? would buying an SSL cert and using https be a solution? Could I use a public/private key type thing?

user1063998
  • 584
  • 6
  • 16
  • I think you should look at http://stackoverflow.com/a/10471429/1226894 – Baba Sep 23 '12 at 13:53
  • 1
    SSL is the obvious solution for transport integrity/confidentiality, but the 'sending bogus requests' part is not solvable by any means - you can't trust the client-side, so you have to check as much as you can on the server side. – bobince Sep 23 '12 at 13:59

1 Answers1

0

Besides the obvious benefits of SSL there are also drawbacks:

  1. You will have to encrypt everything or nothing.

    • This means, that if your site displays third party ads or anything similar, you'll have to make sure all of those are available via secure connection.

    • SSL-encrypted traffic is almost twice the size of non-encrypted. This is going to be especially painful for images and other assets, which you generally don't want to encrypt.

    • SSL encryption is computationally expensive, and will add some % of load on your server (not to worry, unless you have a lot of server-side processing, but for larger applications this is an important factor)

  2. Certificates cost money, have to be updated.

  3. There are some known issues with Flash communicating over SSL and not sending session cookies particularly when using encrypted connection.

Now, usually, you absolutely don't want to implement security on your own. And I wouldn't consider it, if the stakes were high, but I'm not sure what is your particular situation, and I would consider the possibility of doing selective encryption, only for the important things, especially so because the users won't get frightening messages about "insecure" content mixed with "secure" content if you do that in Flash, and not on the browser level.

There are cryptographic libraries out there to do RSA encryption in Flash, similarly, you could do RSA on the server side. Probably the way to do that should be decided based on how well the investment in security will profit the project.