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