This consists of various sub-parts. All of these assume, that the server does not store passwords in plaintext, but in hashed form of some sort (e.g. SCRAM, OPAQUE etc.). There are various reasons to not let servers store passwords in plaintext, if possible. Prosody, for example, stores it's password hashed by default: https://prosody.im/doc/plain_or_hashed
The missing protocol agility was already mentioned on this very list, but no one presented a solution back then: https://mail.jabber.org/pipermail/ standards/2019-January/035720.html Let me stress that the upgrade mechanism defined in SASL2 can not only be used to upgrade between different mechanisms of the SCRAM family, but can be used to upgrade from SCRAM to OPAQUE (or something entirely new), too. 1. Mechanism Announcements SASL1 and the original SASL2 proposal provide no way of introducing new SASL mechanisms for server operators. If, for example, a server operator wants to introduce SCRAM-SHA-256 while previously only supporting SCRAM-SHA-1 (and therefore only having SCRAM-SHA-1 hashes stored on the server), he simply can't do that without causing damage: Globally announcing SCRAM-SHA-256 will make clients happily use it, even though the server still does not have the corresponding hashes and salts in its storage --> authentication will fail. SASL2 therefore contains a way to announce only authentication methods that can be used for a specific user account, not what is globally enabled. It does so by using the from-attribute of the stream-header already present in RFC 6120. That way we did not need to introduce another round-trip. Round-trip reduction is one of the goals of SASL2 and especially important for mobile devices. That does not come without a cost, though: attackers could use this information to determine which accounts are present on the server and maybe even fingerprint which software might be used. Because of this, we suggest multiple counter-measures in the Security Considerations of SASL2: https://dyn.eightysoft.de/final/xep-0388.html#security Namely randomizing the provided mechanisms for not-existing accounts and rate- limiting. Overall I think these security implications are not that big (especially with the suggested countermeasures in place): other parts of XMPP already allow for some sort of fingerprinting (querying OMEMO keys and other open PEP-nodes etc.). 2. Mechanism Upgrades Point 1 would be pretty limited if there was no way of upgrading the SASL mechanisms a server can offer for a specific account. An account registered when only SCRAM-SHA-1 was supported would otherwise virtually stay on SCRAM-SHA-1 forever (more precisely: until the user resets the password of this account). To overcome this limitation, we used the already existing SASL2 tasks to introduce a way for clients to upgrade the server to new SASL mechanisms. The server lists all mechanisms it could support, if it had the needed data in it's storage and the client picks one of these it supports, too, to send the server this needed data. The details depend on the used mechanism (SCRAM, OPAQUE etc.) and are defined in a new ProtoXEP for SCRAM (that's the split-out I announced lately: https://github.com/xsf/xeps/pull/1214/commits/ 251800fabb9ac4fd095f9b04a04f062022c94dbe ). This will make sure the server never sees the cleartext password, if we additionally update XEP-0389: Extensible In-Band Registration to send only hashes, too. This way even an evil or compromised server won't be able to extract your password and potentially use it for credential stuffing. Reducing the attack surface is always good and using hashes for mechanism upgrades rather than cleartext passwords provides for exactly this. -tmolitor _______________________________________________ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: [email protected] _______________________________________________
