9 Replies Latest reply on Dec 5, 2008 1:32 AM by solidated

    7 Things every Adobe AIR Developer should know about Security

    R_Hart
      7 Things every Adobe AIR Developer should know about Security

      1. Your AIR files are really just zip files.
      Don't believe me? Change the .air extension to zip and unzip it with your favorite compression program.
      What does this mean for you the developer? What this means is that if you thought AIR was a compiled protected format, alas it is not.

      2. All your content is easily accessible in the AIR file.
      Since we now that the AIR file is really just a zip file, unzip it and see what's inside. If you have added any content references when you published the AIR file, voila, there it all is.
      What does this mean for you the developer? Well, you content is sitting there ripe for the picking, and so is everything else including you Application descriptor file, images etc.

      3. Code signing your Air app does nothing as far as security for you.
      All code signing your app does is verify to the end user that someone published the app. I does nothing as far as encryption and does nothing to project your content.
      What does this mean for you the developer? We'll you should still do it, because getting publisher "unknown" is worse. It also means that joe hacker would not be able decompile your entire app
      and republish it with the same certificate, unless they somehow got a hold of that too.

      4. All your AIR SWF content is easily decompilable.
      Nothing new here, it's always been this way. Type flash decompiler into google and you'll find a variety of decompilers for under $100 that will take your AIR content swf and expose all your source code and content in no time.
      What does this mean for you the developer? All you content, code, urls and intellectual property is publicly available to anyone with a decompiler, unless you do some extra work and encrypt your swf content files, which is not currently a feature of AIR, but can be done if you do your homework.

      5. Your SQLite databases are easy to get at.
      SQLite datatbases can be accessed from AIR or any other program on you computer that knows how to work with it. Unless you put your database in the local encrypted datastore, or encrypt your entire database it's pretty easy to get at, especially if you create it with a .db extension.
      What does this mean for you the developer? We'll SQLite is very useful, but just keep in mind that your data can be viewed and altered if you're not careful.

      6. The local encrypted datastore is useful, but....
      The local encrypted datastore is useful, but developers need a secure way of getting information into it. Storing usernames, passwords and urls in clear text is a bad idea, since as we discussed, you code is easy to decompile an read. By putting info into the local encrypted datastore, the data is encrypted and very difficult to get at. The problem is, how do you get it into there, without have to store any info that can be read in the air file and without the necessity of communicating with a web server? Even if you called a web service and pushed the returned values into the datastore, this is not ideal, since you may have encoded the urls to you web service into your code, or they intercept the results from the web service call.
      What does this mean for you the developer? Use the local datastore, and hope that we get some new ways of protecting content and data form Adobe in the next release of AIR.

      7. There are some things missing form the current version of AIR (1.1) that could really help ease the concerns of people trying to develop serious applications with AIR.
      Developers want more alternatives for the protection of local content and data. Some of us might want to protect our content and intellectual property, remember not all of us are building toys with AIR. Other than the local encrypted datastore there are not currently any built in options I'm aware of for encrypting other content in the AIR file, unless you roll your own.
      What does this mean for you the developer? We'll I've been told that Adobe takes security very seriously, so I'm optimistic that we'll see some improvements in this area soon. If security is a concern for you as much as it is for me, let them know.
        • 1. Re: 7 Things every Adobe AIR Developer should know about Security
          abeall Level 3
          These are things you should know before you are an Adobe AIR Developer. :)

          Number 6 is a good point... EncryptedLocalStore is great for securely storing user input, but it doesn't help you if you want to include the application installation with secure data. I haven't had to do this, but could you not require that content to be downloaded on first run via HTTPS?

          AIR 1.5 includes native encrypted SQLite databases.
          • 2. Re: 7 Things every Adobe AIR Developer should know about Security
            R_Hart Level 1
            Thanks for responding,

            I totally agree, they should now this, but what I routinely find is that a lot of them do not :-(

            -Would you happen to have any more detail on native encrypted SQLite databases in Air 1.5?
            -Any ideas on how to securely communicate to a sever if SSL and sockets were not an option?

            Cheers
            • 3. Re: 7 Things every Adobe AIR Developer should know about Security
              abeall Level 3
              The extent of my knowledge on AIR 1.5 are from blogs online, such as:
              http://www.mikechambers.com/blog/2008/09/11/adobe-air-15-cosmo-builds-now-in-flex-sdk-nigh tly-builds/

              It don't see any details about the encrypted SQLite db, unfortunately. What I'd be interested to know is if you could deploy an AIR application with an existing encrypted SQLite db...

              If SSL isn't an option, I guess you could theoretically implement your own encryption, which is out of my league, but I've heard of people doing this.
              • 4. Re: 7 Things every Adobe AIR Developer should know about Security
                ilsh Level 1
                I already knew these issues before I built a large serious project -- because I projected Adobe will fix these in the future (it's so easy for Adobe to implement these). I just wish it will come soon (maybe 2.0?)
                • 5. Re: 7 Things every Adobe AIR Developer should know about Security
                  bstegman
                  So its a month later. Does anyone know any more about this? Unfortunately, this issue has forced me to abandon adobe air for any commercial products.
                  • 6. Re: 7 Things every Adobe AIR Developer should know about Security
                    TheDude7563 Level 1
                    Putting "secret data" as a clear text directly in your code is a broken concept in every environment, programing language. Every compiled code is reversible, especially strings are really easy to extract.

                    There is no simple, straightforward way to include secret data directly with your app. This is a complicated subject, and if you really need to do this, you'll need to read up on it a bit.

                    But in most cases this can be avoided or worked around without compromising security. One of the best ways is to provide the user with a simple "secret key" alongside the app (best way is the good old login/password). The user installs the app, and provides his "secret key", that goes directly into EncryptedLocalStore, and then you use this "secret key" to access the "secret data" that's stored on your server. Then you can transfer the "secret data" directly into EncryptedLocalStore.

                    As for the whole thread:

                    Points 1-5 -> Those points do not concern AIR apps only. If you are developing an application in any language, you should follow those rules, meaning:

                    - Code installed on users computer is easy accessible
                    - Data stored locally is easy accessible, even if it encrypted using any symmetric-key encryption, because the encrypting algorithm and encryption key is in your source code (you could probably write a book on using public-key encryption so let's just leave it for now ;)

                    Point 6 -> Is a valid one. All your app security should relay on the EncryptedLocalStore. But it is your job to get the data securely into the ELS, because there is no point to encrypt data that can be intercepted.


                    • 7. Re: 7 Things every Adobe AIR Developer should know about Security
                      bstegman Level 1
                      I guess I'm not as concerned with the whole secret data thing as much as providing my source code to everyone. I am fully aware things can be reverse engineered but you make someone work at it. You don't just give it a way, unless that is your intention. But there is no way I'm spending hours and hours of my time to simply have all my source code just sitting there for anyone to rip off and alter for their own personal benefit. If this is such an invalid argument then please adobe, microsoft, etc etc start releasing all your products with all your source code.

                      Sorry, I guess I should have been more clear on what exactly I was asking about. Has anyone heard any plans on whether air will continue to expect everyone to distribute all their programs as open source.

                      I appreciate your response.. thanks
                      • 8. Re: 7 Things every Adobe AIR Developer should know about Security
                        TheDude7563 Level 1
                        Only thing you can do is to obscure the code using any JS/HTML/CSS minifying tool (Yahoo! makes a good and free one). It will make it harder to reuse your code, but still not impossible.

                        My personal opinion is to just not care about someone reusing your code, and just focus on delivering a great product.

                        And on a side note, I don't think that AIR is appropriate way of making any serious app, that you would like to make money on. AIR is intended to be used to make simple, small apps that work with your website/webservice. AIR will totally suck if you will try to process any large amount of data in it. Not to mention it won't provide necessary tools to do it.
                        • 9. Re: 7 Things every Adobe AIR Developer should know about Security
                          solidated Level 1
                          On number 3, don't forget that even if you sign your code (after having spent $400) on a certificate, customers installing your AIR app will still get an ugly warning (with a yellow icon; you'll never get the green) about how "dangerous" it is to install your program.

                          Thanks Adobe. Good lookin' out for the developer.