Ask HN: Flex/Flash, Authenticating your .swf + decompiling | Hacker News Reader

Ask HN: Flex/Flash, Authenticating your .swf + decompiling

9 pointsarjunlall11 comments

In a nutshell, we are developing a web app where our app and flex fontend need to share data securely. The problem is that our application server needs to know that the requests we are getting from our flex application are not spoofed.

Right now we essentially have a secret key that is hashed with request data to authenticate the flex app.

Problem is, how do we keep the secret key in the flex app code without someone able to snag it by decompiling? I can think of a million ways to obscure the key into the code, but that only will delay a break in, not stop it.

It seems impossible for there to be any secure cryptographic system if an intruder can see the source.

Is there any good way to actually secure flex from getting decompiled? From what I have seen everything just obscures code.

View on HN

Unfortunately, there really isn't a way to do this-

One of the fundamental rules in security training is never trust the client.

Anything you can write, they can open. For the most part, it won't even be that hard. Don't waste time obfuscating it..

If it's at all possible, time would be better spent redesigning the infrastructure such that the client never has any data that you don't want the user to have.. The best way to do this is to generalize an API that the backend uses to talk to the front end. Then, modify your client to use this.

We do this with Chron X- We have a generic Card game API that we call from our Client.. It's not perfect, but we're actively making design decisions assuming that someday, other clients may connect, with or without our consent and blessing. We may never allow it, but we have to work under the mindset that the hackers can do anything our Flex can.

I'd suggest writing a middleware layer, which takes in requests based on a sessionID, and then allows only certain commands to go through, and only certain data to come back. That way, you minimize your exposure.

Newer versions of Flash Player and FMS include remote attestation aka SWF verification; AFAIK it hasn't been cracked yet (but it hasn't been reverse-engineered by Red5 either).

http://livedocs.adobe.com/flashmediaserver/3.0/docs/03_confi...

Hmm... The fact that you're so concerned about requests not hitting your web app without going through your Flex front end raises a red flag...

Anyway, you can obscure the key into the code all you want. If it's a string value there's only one place it will ever be when the .swf is decompiled and that's in the constant pool. If it's a number value stored in a variable or even a few concatenated strings it might be a little more difficult since it's not going to come out and slap somebody in the face, but to say it's trivial to retrieve the key would be the understatement of the decade. Before going this route it might be a good idea to decompile some .swf files to see what it looks like. Check out a program called Describe SWF and take a look at the documentation for Flasm. Lots of good info there.

There's no good way to secure your Flash/Flex code so it's not worth the effort to even entertain the thought. I develop a bot with a custom Flash player and I'm just amazed out how many people do stuff like this. The best advice I can give you is that anything you put in a Flash file is there for the taking as if you were advertising on your home page. Bad idea.

Um, isn't this the same problem as DRM? (which we all know cannot be solved.) The fact is, if my computer can execute the code and make the request, so can I. The only thing you can do is to try to mitigate the risk or make it more difficult.

Yes, same problem. Bummer...

Has anyone had success with making flash decompiling more difficult?

Anyone used http://www.amayeta.com/ ?

My instinct would be: don't bother. If the data you are protecting is worth enough to someone, they will decompile it anyway.

If you can trust the client by having them enter in a password, can't you then set up a system that uses the same idea as public-key cryptography (http://en.wikipedia.org/wiki/Public-key_cryptography)? Once the user has logged in and authenticated with their password they generate their public and private keys and send the server the public key while keeping the private key local. This method would be processor intensive, but good security usually isn't cheap. Or maybe my understanding of how public-key cryptography works isn't accurate and someone can explain why it wouldn't work?

Here's the attack: The user writes software which performs the same authentication handshake as the official client, but after the handshake it starts sending evil messages to the server.

Isn't that where the password comes into play? Basically you authenticate once by passing the password and the client generated public key to the server. The server checks the password and then if it matches it sends all future communication to the client encrypted with their public key. It can generate a new "public" (in quotes because it will only be shared with the client) key specifically for that client and send it encrypted to the client using the public key passed along with the password. All communication from client to server will be decrypted with the private key that matches the public key given to the authenticated client, and all communication from server to client will be decrypted with the private key that matches the public key the client gave to the server with the password. This is probably more like TLS or SSL (http://en.wikipedia.org/wiki/Transport_Layer_Security) than I suppose. Which makes me think you could just use an SSL connection since it is supported (http://livedocs.adobe.com/flex/2/docs/wwhelp/wwhimpl/common/...).

Or am I really missing something and should just stop commenting? :)

The password as the basis for authentication and generating the encryption is useful in this instance to be able to "blame" someone when they are using your service incorrectly. At the very least, you can notify someone to change their password because their account has been compromised. You know _who_ is responsible for the request because it was authenticated.

In other words, your EULA/terms-of-service is a long the lines of "you are responsible for the user of this service using your login credentials, which can be revoked at any time if we perceive you to be violating the terms of service". Then becomes a little more manageable as a social problem (which it is), rather than solely relying on a technical solution to a social problem.

You're authenticating the client? Not the person? That's impossible to do.

Reply on news.ycombinator.com