Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

news.ycombinator.com

Post reply on HN
Print view View original

1–10 of 12 posts

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

#1

Post by 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.

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.

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

#3

Post by arjunlall »

hashtable wrote: post #2

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

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

#4

Post by 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.

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

#7

Post by 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?

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

#8

Post by wmf »

fatjonny wrote: post #7

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 int…

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.

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

#9

Post by sratner »

arjunlall wrote: post #3
hashtable wrote: post #2

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.

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

#10

Post by 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.

Post reply on HN