

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

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.<p>Right now we essentially have a secret key that is hashed with request data to authenticate the flex app.<p>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.<p>It seems impossible for there to be any secure cryptographic system if an intruder can see the source.<p>Is there any good way to actually secure flex from getting decompiled? From what I have seen everything just obscures code.
======
e1ven
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.

------
wmf
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...](http://livedocs.adobe.com/flashmediaserver/3.0/docs/03_configtasks_22.html#1223759)

------
jm4
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.

------
hashtable
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.

~~~
arjunlall
Yes, same problem. Bummer...

Has anyone had success with making flash decompiling more difficult?

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

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

------
fatjonny
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?

~~~
wmf
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.

~~~
fatjonny
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/...](http://livedocs.adobe.com/flex/2/docs/wwhelp/wwhimpl/common/html/wwhelp.htm?context=LiveDocs_Parts&file=00001356.html)).

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

~~~
thwarted
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.

------
ars
You're authenticating the _client_? Not the person? That's impossible to do.

