Hi,
If the secret is stored in the client you may have to even decompile to app to
get at it, just use a reverse proxy and you can see everything sent backward
and forwards even if the app is using SSL.
Justin
Yes, Justin, you can see, but there is nothing secret there :-)
The app secret is used to build a query to Facebook/etc. to get data.
The app secret is appended to the query string and a hash is produced.
If you sniff the resulting hashed data from the network -
you win nothing as attacker.
I am talking about the client_secret string
You can't put that string on a server
You very much can and you very much should. In the specific example of
Facebook, they specifically say that the app secret should never be in any
clientside code, including HTML/JS, native iOS, native Android,
Facebook - yes you can
The 3 other social networks I mentioned - no you can't
On Fri, Feb 28, 2014 at 12:17 AM, Doug McCune d...@dougmccune.com wrote:
Here's the relevant part directly from the Facebook docs:
Therefore the App Secret or an App Access token should never be included
in any
get the
Password back from. Like the saving the crypto-hash of the Password and using
that.
Chris
Von: Alexander Farber alexander.far...@gmail.com
Gesendet: Mittwoch, 26. Februar 2014 08:56
An: users@flex.apache.org
Betreff: Re: Air apps easily
On 26/02/2014 08:23, Christofer Dutz wrote:
But in order to make it 100% safe you would probably have to put an infinite
amount of work into it.
This.
Tom
-1 since someone can take your app,
decompile it, comment/shortcircuit the IAP/DRM
and compile it back - as a cracked version...
Or if you use any OAuth stuff - find the secret
inside the app and then use it to impersonate other users.
On Thu, Feb 20, 2014 at 1:59 AM, Joseph Balderson
You can't keep OAuth secret or
any other secrets at the server side.
If you keep it there, your app needs to download it -
then the attacker can do it as well.
You need something secret to be at the app.
And the ease of decomilation doesn't help there.
On 25/02/2014 13:44, Alexander Farber wrote:
And there was no way to store the OAuth app secret string on the server.
And thus I know that my app is vulnerable (for impersonation of other
users) and the ease of AIR decompilation doesn't help there.
I think you keep insisting, that it's possible
Hello,
On Tue, Feb 25, 2014 at 3:07 PM, Tom Chiverton t...@extravision.com wrote:
On 25/02/2014 13:44, Alexander Farber wrote:
And there was no way to store the OAuth app secret string on the server.
And thus I know that my app is vulnerable (for impersonation of other
users) and the ease
I see, this is one of those cases where you can make a trade off isn't it ?
You can do on-device no-server authentication direct to an API, but this
exposes the secrets to reverse engineering.
Or you can choose to mediate everything via your own server, which
mitigates that issue but drives up
I think I'm missing something, but I'm certainly not an expert in this
area. Where do native apps keep the app-secret if it isn't supposed to
be in client-side code?
-Alex
On 2/25/14 8:00 AM, Tom Chiverton t...@extravision.com wrote:
I see, this is one of those cases where you can make a trade
Hello Alex and Tom,
I am not sure, where native apps
hold the app secret for the OAuth.
For Facebook you can use its
native Android/iOS SDKs...
But for other social networks
you have to use the OAuth flow.
I was just trying to make the point that
sometimes you don't have other options
than to
Anybody else concerned about decompilers like SoThink?
http://www.ericzhang.me/cracking-adobe-air-applications/
-Sean Thayne
Client side can not be trusted, server api should always be the security
gate!
After all there are certain applications that can encrypt Flash
applications, Javascript application is just plain text!!!
On Wed, Feb 19, 2014 at 11:08 AM, Sean Thayne s...@skyseek.com wrote:
Anybody else
You can use SecureSWF.
Works well for Air Desktop and Android Apps
Be careful, max protection level can crash or bug your app
Le 2014-02-19 16:21, Sean Thayne a écrit :
I'm actually more concerned about the plain readability of the AS3,
even
comments are easily viewable. Where as a JS site
To: users@flex.apache.org
Subject: Re: Air apps easily decompiled and hacked
I'm actually more concerned about the plain readability of the AS3, even
comments are easily viewable. Where as a JS site that has been compile with
Google Closures is minimized and heavily obscured. I feel like it would be
very
Are you sure the others that aren't obscured are locals? I'd bet they're
instance variables.
- Gordon
-Original Message-
From: Sean Thayne [mailto:s...@skyseek.com]
Sent: Wednesday, February 19, 2014 12:24 PM
To: users@flex.apache.org
Subject: Re: Air apps easily decompiled and hacked
...@skyseek.com]
Sent: Wednesday, February 19, 2014 12:24 PM
To: users@flex.apache.org
Subject: Re: Air apps easily decompiled and hacked
Ya, you right Alex, I re-checked, and there are not comments. It does keep
trace() calls though.
I also noticed that it does obscure some local vars into _loc_# vars
: Sean Thayne [mailto:s...@skyseek.com]
Sent: Wednesday, February 19, 2014 12:24 PM
To: users@flex.apache.org
Subject: Re: Air apps easily decompiled and hacked
Ya, you right Alex, I re-checked, and there are not comments. It does
keep
trace() calls though.
I also noticed that it does
...@skyseek.com]
Sent: Wednesday, February 19, 2014 12:41 PM
To: users@flex.apache.org
Subject: Re: Air apps easily decompiled and hacked
It looks like every var declared inside a function is obscured/renamed.
But all class vars(regardless of protected, public, private) are not
obscured.
They keep
think that was more for use with Flash player.
David
-Original Message-
From: Sean Thayne s...@skyseek.com
To: users@flex.apache.org
Sent: Wed, 19 Feb 2014 2:40 PM
Subject: Re: Air apps easily decompiled and hacked
It looks like every var declared inside a function is obscured
22 matches
Mail list logo
