[Security] Unsubscribe on Userdelete (Was: [Standards] Password protected rooms)
migri at i-pobox.net
Fri Feb 13 03:26:08 CST 2009
Matthew Wild wrote on the Standard-List:
> On Wed, Feb 11, 2009 at 3:01 PM, Jonathan Schleifer
> <js-xmpp-standards at webkeks.org> wrote:
>> Just a reason NOT to require a PW for the owner: Some admin might have
>> changed it and now the owner can't join the room anymore or change it back.
> That same admin could simply remove the owner from the owner list and be done :)
> This single issue aside however, I do think that the total lack of any
> way to track which services a JID is affiliated with is scary. This
> affects transports/gateways, MUCs, etc. Are roster subscriptions even
> cancelled on account removal?
Thats an very interesting point - in many respects.
Two more examples:
- I have a service with many users from other servers subscribed.
As there is no unsubscribe if the user has been deleted, I have many
"zombie"-subscription. I can only check the subscriptions from my own
server if the accounts still exist. And even that is not so easy.
- A friend subscribed my presence. He was some time in hospital, so I never
noticed, that his account was deleted on the server (due to inactivity?).
As the jid came back online I wrote him gladly, how he is after the
surgery... I realised very late, that the account was now new assigned.
I see only the solution, that there has to be an unsubscribe-request to
every contact in the roster of an user if that user is going to be deleted.
> The hardest case to cover is that of a server going down, and coming
> back up with an empty user database. It is a flaw in our otherwise
> secure identity.
Thats a special problem, as the mentioned solution would no be effective in
The only idea I have for this would be, that the server sends an
unsubscribe-request or an "user-does-not-exist" message if it get something
for an account that does not exist.
But I fear, that this could be used for finding out which jid exist (e.g. to
use that information for spamming) or - even worse - for a DDOS-attack.
> Perhaps it isn't seen as worth solving though? (I
> have seen little discussion of this problem to date)
Thanks for pointing out that issue. Here we go. Any concepts?
More information about the Security