It is not the case here, we only need a way to securely store a secret key
and get it once when the application starts. The important thing here is
actually to make sure only approved applications can access the API, if the
overhead would fullfill the requirement, then it is OK.

I can't think of a solution to this problem unless the OS itself would offer
a way to identify an application through its signing certificate. Any idea
in this direction? can we use that certificate somehow?

Haykel Ben Jemia

Allmas
Web & RIA Development
http://www.allmas-tn.com




On Mon, Sep 26, 2011 at 8:43 PM, Johannes Nel <johannes....@gmail.com>wrote:

> **
>
>
> The problem with making it as hard as possible is the overhead on your
> client application. decrypting a lot of data is a processer intensive
> operation and your own UI could suffer, while someone stealing data could
> decrypt it in C and republish that data unencrypted, giving their UI the
> edge over yours.
>
>
> On Mon, Sep 26, 2011 at 6:45 PM, Haykel BEN JEMIA <hayke...@gmail.com>wrote:
>
>> **
>>
>>
>> yeah you have just confirmed my 'fear' that for client applications there
>> is actually no secure way to identify them because anything they include
>> (data, algorithms etc.) can be cracked and the identification process can be
>> reproduced. We can only try to make it as hard as possible.
>>
>>
>> Haykel Ben Jemia
>>
>> Allmas
>> Web & RIA Development
>> http://www.allmas-tn.com
>>
>>
>>
>>
>> On Mon, Sep 26, 2011 at 1:35 PM, claudiu ursica <the_bran...@yahoo.com>wrote:
>>
>>> **
>>>
>>>
>>> The thing is that most client side apps implement security by obscurity
>>> which pretty much means that you will never be safe 100%, the only thing you
>>> do is not putting it in plain sight. So as you continue is add more level of
>>> obscurity, but as said that will only make it harder still not impossible to
>>> crack. You can double/triple that by server side checks e.g. trusted ips,
>>> domains, user etc. Whenever server feels like there is not enough trust
>>> should deny the connection.
>>>
>>> Obviously the topic is large enough to tackle in just a couple of lines,
>>> hopes this gives you a start ...
>>> C
>>>
>>> ------------------------------
>>> *From:* Haykel BEN JEMIA <hayke...@gmail.com>
>>> *To:* flexcoders@yahoogroups.com
>>> *Sent:* Monday, September 26, 2011 1:40 PM
>>> *Subject:* Re: [flexcoders] Restrict access to an API to only allowed
>>> applications
>>>
>>>
>>> Thanks Claudiu,
>>>
>>> I have found a PDF of the presentation and on page 4 it says the
>>> following about protecting sensitive data through embedding:
>>>
>>> * Most decompilers don’t look at embedded data.
>>> * Given that SWF is an open file format, nothing is really stopping them
>>> from doing this in the future.
>>> * Useful for quick/dirty storage of WebService credentials.
>>>
>>> So this is definitly better than storing the keys in plain text format,
>>> but still easy to crack.
>>>
>>> Any other suggestions.
>>>
>>> Thanks,
>>>
>>> Haykel Ben Jemia
>>>
>>> Allmas
>>> Web & RIA Development
>>> http://www.allmas-tn.com
>>>
>>>
>>>
>>>
>>> On Mon, Sep 26, 2011 at 11:33 AM, claudiu ursica 
>>> <the_bran...@yahoo.com>wrote:
>>>
>>> **
>>>
>>>  You can embed the keys instead of keeping them in plain site.
>>>
>>> check this session I think you will find some useful stuff:
>>>
>>> http://tv.adobe.com/watch/360flex-conference/encrypting-flex-protecting-revenue-by-andrew-westberg/
>>>
>>> C
>>>
>>> ------------------------------
>>> *From:* Haykel BEN JEMIA <hayke...@gmail.com>
>>> *To:* flexcoders <flexcoders@yahoogroups.com>
>>> *Sent:* Monday, September 26, 2011 12:00 PM
>>> *Subject:* [flexcoders] Restrict access to an API to only allowed
>>> applications
>>>
>>>
>>> Hi,
>>>
>>> I'm looking for the best and most secure way to restrict access to a web
>>> API to only allowed applications. The best option I found is to use 2-Legged
>>> OAuth where applications would get a consumer key and a secret key. The
>>> problem here is that SWF files can be easily decompiled and the keys
>>> extracted. My questions here are:
>>>
>>> * Does anybody know a way to protect the keys?
>>> * Is there another authorization mechanism that is better suited for such
>>> client applications in general (Flash, JavaScript ...)
>>>
>>> Thanks.
>>>
>>> Haykel Ben Jemia
>>>
>>> Allmas
>>> Web & RIA Development
>>> http://www.allmas-tn.com
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>
>
>
> --
> j:pn
> \\no comment
>
>  
>

Reply via email to