Does an actionscript decompiler get actionscript from dynamically linked as files?

I am creating a Flex 4 project and would like to do an actionscript based login with encryption, but I obviously don't want it to be easily decompiled. If I dynamically link to a swf file that is in a "non-browse" directory, would a decompiler of the base application actionscript file also give the code of the linked file?

For example

[Base Directory] index.html app.swf [Modules] --This directory is made non-browseable-- login.swf

t开发者_JAVA百科he app.swf imports login.swf on load.

What do you mean by non-browsable? If the app.swf running on the user's machine has access to load login.swf at runtime, then login.swf is publicly readable. If it is publicly readable, it can easily be downloaded and decompiled.

You can never safely embed a "secret" into a SWF, and you can never safely authenticate the client (only the user). Perhaps more importantly, a secure login shouldn't require you to implement encryption in the first place. Generally speaking, the best practice is to send login information over HTTPS and let the browser's transport layer handle the encryption for you. It should be transparent to your Flex application.

What a decompiler will give you is the code and assets of the swf you are decompiling.

As well, based on what I have seen from the decompilers currently available, you will not see the code and assets in the child swf that your primary parent swf loads, unless you copy it and decompile that swf too; however, this is extremely easy to do, as you can simply copy it from your cache.

You should just get used to the idea that everyone will be able to see your code if they want to, even if you obfuscate it, and that you should be separating the presentation code residing on the client side from the backend for security on the server side.

Design your logic just as you would if it were an HTML login form, where for security reasons, because the user can easily view the source, you would always need to rely on the server-side for authentication and validation, rather than code that would be residing and running on the client-side.

If the code is on the client-side, than the user can do with that code as he or she pleases, and, if the user is skilled enough, there really isn't anything you can do to stop him or her from messing with it.