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
_______________________________________________

Reply via email to