> On Aug 20, 9:00 am, Sunir <su...@freshbooks.com> wrote:
>> It's insufficient to provide a key for each device, since the key can
>> be cloned by an attacker and used on another device. e.g. if you gave
>> Alice the consumer key AlicesPhone for her mobile, she could give her
>> key to Bob and he can use it on his mobile and pretend to be Alice.

On 20-Aug-09, at 9:11 PM, John Kristian wrote:
> A user should be responsible for his access token secret. If he
> reveals it to an attacker, he should expect the attacker can
> impersonate him, just as if he gave his authorized mobile device to
> the attacker. An application can help prevent such a mistake, by
> making it difficult for the user to find his token secret.

Sorry, the original proposal as I understood it was that every  
application gets a consumer secret for each mobile device. Presumably  
you could arrange this by cooking the binary every download with a  
different consumer secret. This is impossible in mobile environments  
with centralized distribution (iTunes, AppWorld). However, in those  
environments, this isn't really a problem.

(Frankly, using a trusted central distributor is the correct security  
and market solution even if it costs a significant cut of revenue.)

My first reaction was that there is no way to avoid piracy, since if  
Pirate Alice downloaded the app, she could post it on the Internet and  
anyone (i.e. Bob) could use it. However, I realize now that isn't the  
case, since you can monitor the use of the consumer secret, and if one  
secret seems overly used, you can destroy it disabling all pirates.  
Hello Windows Genuine Advantage.

However, I would add in response to your suggestion, you should not  
rely on the premise that it is hard for the user to find their token  
secret since it is so easy to retrieve with common reverse engineering  
tools.

What you can do is make this slightly harder by binding the secret to  
the mobile number and have the app self-verify this. A cracker would  
have to modify the binary to jump around the verification (trivial),  
but if the app was digitally signed, that could be effective.

Cheers,
Sunir Shah, Chief Handshaker, FreshBooks
(416) 481-6946 x224
http://www.freshbooks.com/team/sunir
http://twitter.com/sunir


--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups 
"OAuth" group.
To post to this group, send email to oauth@googlegroups.com
To unsubscribe from this group, send email to oauth+unsubscr...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/oauth?hl=en
-~----------~----~----~----~------~----~------~--~---

Reply via email to