In that case, as the prizes are large and the audience will include hackers, I'd go with a combination. Here's a few ideas off the top of my head, some of them may be stupid, others too expensive to implement depending on your prize money / risk of actual damages to your company if it gets hacked (ie if you get sued or look like douchebags, as well as paying some hacker the prize).
Start with SSH Turn off crossdomain.xml :) Perhaps include something along the lines of an embedded signed java Applet to verify an MD5 of the .swf file Only bother with the encryption if it's within a certain distance of high score, to cut down on server load Have the SWF download the decryption module (perhaps using a unique url it gets from the signed java applet, just to make it slightly harder to simulate the Flash environment) when needed and timeout - as mentioned already Maybe generate a new encryption algorithm SWF every time - could be server expensive, as well as a programmatic challenge Maintain a pool of encryptor-decrypter pairs (cryptdecs?), choose one at random instead of a new one every time. But still have either people or software coming up with new ones and retiring old ones. Depending on the game, include in your "high score" packet some information that would be able to let a server-side simulation give you some sort of "chances of actually getting this score from these starting conditions and log of commands" score Statistical analysis of the score history of the userbase as a whole, users in the top 80-90ish percentile, and compare it to the winner Anybody else have any ideas to throw in? Or better yet find a flaw in mine? This is definitely an interesting topic! -J Before you do anything funky, download the current high score - if the app doesn't think the user has beaten it On Wed, May 28, 2008 at 4:26 AM, kenny14390 <[EMAIL PROTECTED]> wrote: > > > There is no such thing as Flash application security? > > > > Against what ? > > How much is the value of the prize ? > > Who is attacking you ? Why ? > > The prizes are pretty big, so there is a justified concern for > security. The "attackers" would be facebook users, so they will > usually be 18-25. > > --- In [email protected] <flexcoders%40yahoogroups.com>, Tom > Chiverton <[EMAIL PROTECTED]> > wrote: > > > > > On Tuesday 27 May 2008, kenny14390 wrote: > > > Is the simple conclusion that Flash applications are inherently > > > transparent? > > > > Yes, same as a HTML application, in a sense. This is the bane of > client/server > > computing, and *banks* haven't cracked it yet either. > > However, there are less people with the skills to decompile a Flex > app than a > > JavaScript one. But maybe all they need to do is sniff the network > traffic... > > > > > Does SSL patch any of these risks? > > > > No, because the user can configure an SSL proxy and see the plain > text of the > > session. But, again, less people will be able to do this. > > > > > There is no such thing as Flash application security? > > > > Against what ? > > How much is the value of the prize ? > > Who is attacking you ? Why ? > > > > Until you answer those questions, how can you evaluate any of the > various > > mitigation's ? > > For instance, if your attackers are all under 10 (because your app > is used in > > a closed environment, i.e. a school class room, and the login is > tied to the > > attendance list and O/S logged in user) then you probably don't need > to do > > anything else. > > > > > How can a "high score" problem be overcome? > > > > Some sort of CAPTCHA type test should prove there is a user sat at the > > computer, but I'm not aware of anyway to verify they're using your > client and > > not another one they built themselves. > > Given they can intercept your 'calculateChecksumOfYourself()' (or > whatever) > > and just send back the 'right' answer. > > > > A lot of the time, raising the bar fairly high (require login, SSL) is > > probably good enough. > > In your case, I'd probably want to require unique, verified email > address too. > > Maybe postal too as people tend to have fewer throw away postal > address' that > > actually work :-) > > > > -- > > Tom Chiverton > > > > **************************************************** > > > > This email is sent for and on behalf of Halliwells LLP. > > > > Halliwells LLP is a limited liability partnership registered in > England and Wales under registered number OC307980 whose registered > office address is at Halliwells LLP, 3 Hardman Square, Spinningfields, > Manchester, M3 3EB. A list of members is available for inspection at > the registered office. Any reference to a partner in relation to > Halliwells LLP means a member of Halliwells LLP. Regulated by The > Solicitors Regulation Authority. > > > > CONFIDENTIALITY > > > > This email is intended only for the use of the addressee named above > and may be confidential or legally privileged. If you are not the > addressee you must not read it and must not use any information > contained in nor copy it nor inform any person other than Halliwells > LLP or the addressee of its existence or contents. If you have > received this email in error please delete it and notify Halliwells > LLP IT Department on 0870 365 2500. > > > > For more information about Halliwells LLP visit www.halliwells.com. > > > > > -- "Therefore, send not to know For whom the bell tolls. It tolls for thee." :: Josh 'G-Funk' McDonald :: 0437 221 380 :: [EMAIL PROTECTED]
