Kenny, are you saying you want to implement security *within* your Flex app? I think you'd have serious security holes with that (your decompilation concern, for one). Typically security would be handled at the client-server level, by hosting your SWF on a server that has been configured to accept connections over https (e.g., https://myserver.com/myapp), connecting to your app via HTTPS from a browser, and designing your Flex app to connect to other servers over HTTPS as well. Web servers and browsers already have built-in implementations of RSA, SSL/TLS, and the other "industry standards" mentioned in other posts so there's really no need to implement them yourself. The same SWF (with certain design considerations taken into account, of course) can be accessed on the web non-securely (over HTTP), or securely (over HTTPS).
HTH, Doug --- In flexcoders@yahoogroups.com, "kenny14390" <[EMAIL PROTECTED]> wrote: > > So the bottom line is to use an algorithm like RSA? To take a much > simpler example, if the Flex app receives the encrypted data "1234" > and it wishes to use that data, it must first decrypt it. So it > performs the decryption in some AS and now you have the decrypted data > that you wanted. My question now is, if someone decompiles your app > they can see your decryption method and thus decode the data on their > own. Nothing is private in the Flex app due to the decompilation concern. > > Regarding SSL, I suppose this is out of the question if we're talking > about a Facebook application. I don't have much control over their > security. > > --- In flexcoders@yahoogroups.com, "andrewwestberg" > <andrewwestberg@> wrote: > > > > I think you're confusing simple secret key encryption (DES, AES, > > etc..) with public/private key encryption (RSA). > > > > In secret-key encryption if an attacker steals the data and guesses or > > brute forces the secret key, they can see the data. > > > > In public/private key encryption, a message you send to the server is > > encrypted by a public key and can ONLY be decrypted by a private key > > known only to the webserver (the certificate you bought from verisign, > > thawte, etc...) This is how when you sign onto paypal or some other > > site over https, you don't have to worry about your credit-card being > > stolen in transmission. Sitting in some DB at the company where > > employees can get at it, you should worry, but during transmission, > > it's unlikely to get cracked. > > > > -Andrew > > >
