On Thu Oct 21 23:58:22 2010, Alex Milowski wrote:
I don't see how having a non-cleartext authentication mechanism for
MUC rooms changes any security issues that might already be present
via a MUC room service.
Well, I think that's really my point, right there.
Given an attacker who is in a position to hijack C2S or S2S streams
and inject stanzas, mere replacement of a plaintext method with even
a challenge/response-based hash method doesn't appear to change the
security issues of MUC all that much at all.
All, in fact, it protects against (that a plaintext password doesn't)
is that a purely passive easvesdropper cannot acquire the password.
But if that's your sole threat, then Kurt's original salted hash is
fine, sans timestamp.
On the other hand, if you're concerned about tampering with the
stanzas between the client and the service to any degree, then of
course you note Kurt's hash replays. But, equally, so does all the
other traffic, allowing someone to hijack a stream and inject any
other traffic they choose the moment their victim has joined, leaving
all the traffic in the MUC - that presumably you're trying to
establish trust for - vulnerable to a wide range of attacks.
To put it another way, even if you proof the join request against
replay and spoofing, such that it becomes a (mythical) perfectly
secure operation, it'll still be rather like having a six-inch thick
steel front door but leaving all your windows open.
Therefore, in order to minimize round-trips and provide security, you
need to:
1) Sign all the stanzas with a certificate trusted by the MUC service.
2) Arrange some mechanism for provisioning that certificate. (Which
might be a prearranged common trust anchor, or some mechanism whereby
the client authenticates in a more complex manner with the MUC
service as a one-off to agree on, or sign, a certificate.)
It's this latter case where I propose using SASL, not in the MUC join.
I'm not saying, by the way, that I feel this model is at all
sensible. I think it's a fantastic overkill. But it's a sensible
option *if* you think the threat model includes a likely injection
attack, including replay.
This is why I've been trying to figure out exactly what your threat
model is - that is, what potential attacks you're attempting to
protect against - in order to figure out how far we need to go to
mitigate those attacks.
Dave.
--
Dave Cridland - mailto:[email protected] - xmpp:[email protected]
- acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
- http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade
_______________________________________________
JDev mailing list
Forum: http://www.jabberforum.org/forumdisplay.php?f=20
Info: http://mail.jabber.org/mailman/listinfo/jdev
Unsubscribe: [email protected]
_______________________________________________
