Hi Thilo, On Wed, 2022-10-19 at 21:41 +0200, Thilo Molitor wrote: > I want us to move away from that "PLAIN is sometimes needed, let's > support > it in all relevant clients without further interaction by the user > and ignore > any security implications this might have" stance that seems be > common, to > something like "only support PLAIN in clients after configured to do > so, to not > allow for trivial MITM attacks". > That's essentially a "default secure" rather a "default insecure" > approach.
You make it sound as if PLAIN over TLS was anywhere near insecure. It's not. It's what is protecting your emails, your online banking, your tax declaration, ... (at least on first connection, some of these can store a token for further use instead of the plain password). The main advantage of SCRAM is that clients don't need to store the plain password, but can store the SaltedPassword instead. This is still a valid credential, but it is restricted to the server (as each server would have it's own salt), so if users reuse passwords (which they shouldn't, but do anyways), it's not as much of an issue, if the XMPP client is attacked, as only the XMPP account would be affected. Under certain extreme conditions it might be sensible to put some kind of additional security to TLS, for example Signal is known to use certificate pinning with their own CA. And for these special cases it's worth having something like SCRAM with channel binding specified (and both defaulting to it and pinning to it is somewhat sensible). But that doesn't mean we should frame PLAIN over TLS as insecure. It's not. It also doesn't allow for trivial MITM attacks: If a public CA was to issue certificates it shouldn't issue, it will get banned immediately (and thanks to certificate transparency we will learn about this close to immediately). And if a private CA was installed onto a system, the attacker could have installed malware at the same time, that would be able to fish the user's password and thereby break SCRAM's channel binding. Given that there are always usecases where SCRAM cannot be used (RFC already mentioned PAM and LDAP, but there are even further, basically everything where credentials are not handled by the XMPP server itself) > I've split out the SCRAM upgrade task definition into a new ProtoXEP: > https:// > github.com/tmolitor-stud-tu/xeps/tree/scram-upgrades > Rendered version: > https://dyn.eightysoft.de/final/xep-scram-upgrade.html Just wanted to mention that this specification isn't really a "SCRAM upgrade", but rather a "change salted password" specification (which might be an interesting idea to have, but that's another story), because the server has no way to verify that the salted password is the same as the previous one when upgrading from SCRAM-SHA-1 to SCRAM-SHA- 256. I also question the proposed upgrade mechanism in general. The server can only suggest mechanisms independent of the user's account name. If the server previously only stored SCRAM-SHA-1 secrets and some users upgraded but others didn't, the list can't be used meaningfully. What we'd need here is a new error code for the server to tell the client after the <authenticate> message that the user can't use SCRAM-SHA-256 yet, but will be able to do so after some upgrade operation being performed (which probably entails sending the password in plain). A client that is trying to do SCRAM-SHA-256 when the server doesn't have matching credentials yet must have the plain password at hand already (as it can't have the SaltedPassword yet due to lack of salt), so it is already prepared to provide it. If channel binding is desired for security reasons, one could also do a SCRAM-SHA-1-PLUS before sending the password to the server in plain. Marvin _______________________________________________ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org _______________________________________________