On Tue, 17 Dec 2024 at 14:57, Daniel Gultsch <[email protected]> wrote:
> 4. Do you have any security concerns related to this specification? > > Yes. 4.1 says that occupant ids "SHOULD" be unique to that MUC room; that is, other rooms on the service "SHOULD NOT" use the same identifier for the same room. This is highly problematic, since if a user is open about their identity in the (example) C++ room, they may inadvertantly reveal their identity in the (example) Java room, causing them huge embarrassment. Why is this a SHOULD? > 5. Is the specification accurate and clearly written? > Modulo the perennial problem of confusing "anonymous" with "pseudonymous", yes. Perhaps understandably, the security issue above results from pseudonymity, rather than anonymity. Also, I think a more pseudocode-ish suggestion for implementation might be useful, and that might also result in a simpler suggestion: You have (roughly) HMAC(room_secret, bare_jid) - sensible, but you can get a more efficient mechanism if you do: HMAC(server_secret, bare_jid || NUL || room_jid) - the limitation here is that destroying and recreating the room with the same jid will use the same occupant ids; the advantage is that it needs only a new global variable to hold a single secret, which is trivial in config. If your programming language doesn't like string concatenation with NUL, just use "/" instead. This might also avoid the SHOULD; assuming that was predicating on data storage needs or something. (Aside: it recommends HMAC with a suitably strong hash algorithm; astonishingly even MD5 is strong enough here - I wouldn't recommend changing the text, mind, but for those on this list, use whatever hash algorithm is easiest).
_______________________________________________ Standards mailing list -- [email protected] To unsubscribe send an email to [email protected]
