Apps Messaging: security

John Taylor jontayler at gmail.com
Tue Apr 10 05:40:44 PDT 2007


On 10 Apr 2007, at 13:31, Mark Taylor wrote:

> On Tue, 10 Apr 2007, John Taylor wrote:
>
>>> It is probably wise to make that information available, for instance
>>> there may be messages which pass around the public IDs of an  
>>> application
>>> which originated a data object, and the originating application  
>>> might
>>> need to identify itself in this context.  In which case it looks  
>>> like
>>>
>>>   (secret-id,public-id) = register*(hub-secret)
>>
>> Yes, that's probably better than providing a
>>
>> public-id=getPublicId(secret-id)
>>
>> which would be vulnerable to brute force.  Alternatively, we could  
>> define the
>
> actually that would be OK, and maybe tidier - we're vulnerable to  
> brute force in any case (app.exec(secret-id,args="rm -r .")). We  
> can just recommend that secret-ids ought to be hard to guess.

I guess so - I was thinking that a brute force attack on the former  
allows you to get a particular application, while in the latter the  
bad guy  can't be sure which app you'll get.  I guess there's not  
much of a difference...  Anyway, all we're trying to do is stop one  
application spoofing another.  A malicious application can still  
register legitimately and send a naughty command.  I don't see any  
way of stopping that - if you're going to run dodgy software it can  
execute "rm -r" on its own without our help!

>
>> public id of an app to be a digest of the private id.  Too  
>> complicated?
>
> neat, but would require access to MD5 libraries or whatever in  
> application
> code which is undesirable.



More information about the apps mailing list