[jdev] Alternate MUC Authentication Mechanisms
Matthew A. Miller
linuxwolf at outer-planes.net
Fri Oct 22 07:49:49 CST 2010
On Oct 22, 2010, at 04:29, Simon Tennant (buddycloud) wrote:
> On 22/10/2010 04:05, Kurt Zeilenga wrote:
>> So my previous suggestion was subject to a limited replay attack. In particular, someone who was able to hijack the C2S, S2S, or the intermediate server could do a replay. Here's another suggestion that eliminates this replay attack and doesn't require any additional roadtrips.
> Doesn't the idea of having a shared secret between users invalidate all technical security measures?
>
> Traffic can be intercepted, replayed and whatever... but sharing a secret between users as a way to access a common resource without a per-user audit trail, seems like something that should never fly in the first place. Especially not in 2010.
>
> If your MUC's content is really so sekrit, permission on jids, not using a shared secret. Shared secrets should really just be deprecated IMHO.
This was going to be my suggestion. A members-only, closed-registration room would do the trick, mostly. It won't prevent the case of a hijacking of the S2S (or even C2S) connection to the extent which the attacker can impersonate an allowed member of the room. But then, you might have bigger problems at that point...
- m&m
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2238 bytes
Desc: not available
URL: <https://www.jabber.org/jdev/attachments/20101022/fc145cf0/attachment.bin>
More information about the JDev
mailing list