December 2010
« Nov   Jan »



« | Main | »

Securing your keys within SWF?

By Rich Tretola | December 7, 2010

We all know that SWF is not secure and can be easily decrypted by many tools that I won’t mention here. So, if you are building browser or desktop/mobile (AIR) flash applications that use public services (REST, WSDL) with tokens for API identification, how are you securing your tokens?

Please let me know your techniques.

Topics: Adobe AIR, flash, Flex, Flex 4, mobile | 12 Comments »

12 Responses to “Securing your keys within SWF?”

  1. Milen Says:
    December 8th, 2010 at 3:24 am

    Well, it’s really hard , but my favorite solution is actionscript obfuscator. I tried many of them (maybe all on the market) and my advice is to choose . Really good obfuscator with many options

    Reply to this comment

  2. Mário Santos Says:
    December 8th, 2010 at 9:03 am

    A great post and i’m curious about the replys…

    I’m using SWF Encrypt from Amayeta. The only tool that until today makes my swf’s secure.

    It simply crashes most decompilation softwares out there…

    I have tried almost every product out there for encryption and all the decompilers, and the best results were provided by SWF Encrypt.

    Reply to this comment

  3. Mandrake Says:
    December 8th, 2010 at 11:03 am

    No good way to do it. If you want to do it from within the client, it can be tracked by using something like Firebug or a network proxy on the client. That would give you all the details of the request and the response.

    You will need to write a server side counterpart and use that to hide your keys (though even that is not fool proof). You can increase the security here by using secure connections and post requests.

    Reply to this comment

    Rich Tretola Reply:

    Charles Proxy will still show post values even over SSL.

    Reply to this comment

    Michael Wills Reply:

    I would have thought Mandrake’s solution would require tying a session to the request so the client never actually sees or accesses the key. In essence the server side is a proxy for the requests.

    And yeah Charles Proxy is great. Been using it for quite some time now! :)

    Reply to this comment

  4. Pieter Van den Bosch Says:
    December 8th, 2010 at 12:08 pm

    Although no setup is completely safe, this one has worked for me.

    Hide a key in your swf & generate one on the server side.

    First you have to hide a key in the first swf you serve to the client. You’ll always have two versions of this swf. One with the real key and one with a fake one. With Htacces you can redirect every call to eg. preloader.swf to a serverside script. If the referral of the call is your page the swf is supposed to load from, serve the genuine swf. Otherwise someone is trying to download the file for decompiling and you serve the fake swf.

    Once the swf is initialized request an additional server token, regenerate a new token with every call.

    Use these two strings to encrypt/decrypt your data.

    This is just the first step in securing your communication but I’ll have to write a real article to cover it all :-)

    Reply to this comment

  5. Hristo Says:
    December 8th, 2010 at 9:26 pm

    Guys – seriously – this conversation is OUT OF CONTROL
    All of this is misleading and wrong


    The only solution to hiding valuable data / passwords in your compiled flash code is for the data to not be valuable enough for anyone to bother decompiling your swf.

    Just don’t put your passwords in it.
    Just don’t.

    The only way to protect your API is to make it secure, and distribute API access keys to API users in order to create accountability. If anyone is abusing the system, cut him/her out – that’s as good as you can do in managing the problem of evil API access.

    One last thing – why would you even try to limit users in terms of the tools they would use to access the API? Wasn’t the idea of an API to be open for applications to connect to?

    Reply to this comment

  6. Andrew Westberg Says:
    December 9th, 2010 at 8:44 am

    I put them in a Nitro-LM license variable. After a successful authentication, I then retrieve them from the license.

    Reply to this comment

    Rich Tretola Reply:


    Can you explain a little more about how this works?

    Reply to this comment

  7. Andrew Westberg Says:
    December 9th, 2010 at 12:38 pm


    You embed a public key in your app used to communicate with the servers. You authenticate with e-mail/password and download an encrypted license block via this secured channel. You can define license variables in the Nitro-LM Admin tool that’ll be delivered along with a license and securely stored inside the license. You can then use the LM API to retrieve your variables that you defined on the server from the encrypted license block. Granted, this still won’t stop someone from dumping application memory once you’ve pulled your keys out of the license block, but it goes quite a ways to discourage people from trying.

    Reply to this comment

    Rich Tretola Reply:

    Right, but what about if you do not require a username and password. The keys I am talking about are the developer api keys for REST services.

    Reply to this comment

  8. Cameron Childress Says:
    December 10th, 2010 at 1:33 pm

    Since REST services are going to generally be sending your developer API key along with all or at least some REST calls it doesn’t really matter where you hide it. The weakest link in the chain will be the HTTP or HTTPS transmission.

    Usually you are going to combine your Developer API token with a session token anyway so stealing the dev API token isn’t going to allow someone to do much of anything except pretend to be your application.


    Reply to this comment