PDA

View Full Version : Securing flash application with SSL


mondobiondo
01-30-2010, 08:23 AM
Hi!

I've read a bunch of postings but I am still not clear about how to achieve flash security *when it comes to SSL*, so here goes...

I am making a flash application using php and MySQL as backend on a dedicated server. I use Flash CS3/Actionscript 3.

Some details:
- The contents of the database is not super sensitive - more like facebook personal data
- There is a membership system with a handful of subscription options that will be paid for via an external payment provider (i.e. NOT a flash based solution). So that part should be secured already.

So, what remains is to secure the rest of the site with SSL.

As far as I see it I have to options:

A. Use SSL to secure ONLY the functions sending/creating passwords (register, logging in, changing password) and leave all other functionality unsecured. In other words, a session can still be sniffed and hi-jacked once a user has logged in, and any information sent during sessions can also be sniffed since the information is sent uncrypted.

B. Enable SSL for the whole site. This means that apart from the security achieved in option A, now also sessions and all information sent during sessions are secured. Of course, even if I go for option B, a hacker can still sniff "Forgotten your-password"-emails sent to a client.

Here are my questions:

1. Is my reasoning sound so far?
2. In option A, how do I secure specific functions, such as logging in?
3. Under what circumstance should I go for option B? And when should I go for option A? By the way, seems like Facebook uses option A?

Thanks for reading!

mondobiondo

tadster
01-30-2010, 05:59 PM
You should use option B, however, it is possible to encrypt things without SSL

mondobiondo
01-30-2010, 10:50 PM
Hi tadster. Thanks for your reply!

So you mean skip SSL and use some other form of encryption that is faster? do you have a recommendation?

Barna Biro
01-31-2010, 12:34 AM
What tadster was trying to say is that you don't have to boil everything down to SSL. People were implemention security way before SSL was invented. SSL in essence, easens the life of those who are too lazy to implement a needed security level from scratch.

So, the way you choose to solve your security issues is totally up to you. All that you need to know is that not everything comes down to SSL... if you think that SSL can't solve your problem the way it should, then find a different solution or implement/invent your own.

mondobiondo
01-31-2010, 10:25 AM
Hi Barna Biro. I want something that works and that people passionate about security have developed. I'm passionate about other parts of development - and a day only has 24 hours.

So, a pointer in the right direction would be really helpful.

Thanks!

tadster
01-31-2010, 06:50 PM
There is a lot to it, for a start you can read up on cipher algorithms.
The goal is to encrypt (code) whatever is "sniffable" in such a way that just by looking at it, it can not be understood. And then keep whatever decodes the code, safe and away from the transerfing data.

You can pass everything around as binary data (AMFPHP) which makes hacking a bit harder.
You can create your own unique cipher to code or encrypt everything and anything that is "sniffable"

pj-co
02-03-2010, 06:31 AM
I would say dont bother with all that. Use SSL on the stuff that matters and sessions with a short timeout for everything else. This is the way most all sites work. Heck, even Gmail used to work like this (they have since gone all SSL).

But if you're really paranoid I would read up on public key cryptography but dont create your own cipher heh, (unless you're really interested in it). The trick will probably be in creating the handshake.


AES, Blowfish, or MD5(one way) will suit your needs fine. Also, the Wikipedia article on public key cryptography is surpisingly readable and not as super technical as the stuff on ciphers.

http://en.wikipedia.org/wiki/Public-key_cryptography

If you really get nuts, read up on Diffie & Hellman :)

http://en.wikipedia.org/wiki/Diffie-Hellman

mondobiondo
02-06-2010, 10:49 AM
Hi pj-co. Thanks! When you say "short session timeouts" what do you mean? 30 minutes or so? And what kind of attacks does that prevent? In my mind the main threat after logging in would be someone sniffing the session id in which case even 30 minutes is quite a long time to get the session id and cause harm?

I'm thinking that an alternative to going "all SSL" would be to combine SSL protection during login with a fast light-weight encryption to protect the sessions. The information in my system won't be very sensitive but raising the bar just a bit - that is, not sending it in plain text, would be enough, I think.

Apart from the general reads you suggested, is there some AS3 SSL function library or something, that you know of, that I can play around with?

Also, are there any major pitfalls that I should avoid during SSL implementation? Such as browser incompatibility or the like?

pj-co
02-08-2010, 05:46 AM
I'm not a security or SSL expert but I would imagine 5-10 minute session would be plenty. Basically you have PHP extend the session each time it gets a http request with a valid session. This prevents people from just cutting and pasting URLs or entering in random URLS to try and get user info mostly.

I know there are MD5 AS libraries and might be some AES, but you'll have to google to find out. I'd imagine one way to try and encrypt would be to send some of the flash over the SSL connection and have that flash create it's public and private key. At this point you can stop using SSL. Then your server could send the flash a public key by which to encrypt with, and the flash could send it's public key to the server. They can now exchange data by encrypting any data they need to send with the other's public key.

These keys would also only be valid for the length of the session. If the session times out, the server should redirect the user to login again and you would begin the process all over.

Mind you, this is far from perfect security and I am no expert, so please take it with a grain of salt (pun sort of intended) and do you own research. Good luck, and I would be glad to hear about how you ended up solving the problem.

mondobiondo
02-08-2010, 01:48 PM
Ok, time for more googling, I guess. Thanks, pj-co!

mondobiondo

NoobsArePeople2
02-10-2010, 10:38 PM
- The contents of the database is not super sensitive - more like facebook personal data

What site is this for? I feel my personal data is SUPER sensitive. :)

mondobiondo
02-11-2010, 10:22 PM
Well, compared to say financial information, credit card numbers, etc I'd say that my email address or home address is not as sensitive. Not to say that I would like that information being hacked, though, or that such information should not be protected. And sure, in the facebook case, you can definitely cause a lot of damage if you break into some guys account and post bad stuff to his friends.

mondobiondo