Huh, I didn't realize that SCRAM is this widely supported https://xmpp.net/reports.php
Thanks for the hint!
Indeed it was my mistake when I searched for authentication mechanisms, which aren't concerned with the initial exchange.
Still, as a non-cryptographer, I have to wonder if it's possible to make a password work while using public key crptography. Perhaps the way SSH does it: use password to unlock the private key, but only send the public key?
In theory... I don't know if there's any established auth method like this, that would eg. generate ed25519 secret key from a password, and used pubkey from it to send to the server when creating account or changing passwords and server using some challenge response, to authenticate users.
The article clearly mentions that passwords are sent in cleartext to the server when the user sets/changes their password. It even clarifies that SCAM-SHA-1 won't help as hashing happens after cleartext password can be logged.
> loglevel: 5 (or “debug”) logs every single message and all activities mentioned above plus passwords in cleartext. Some XMPP proponents insisted that this isn’t true as XMPP servers use SCRAM-SHA-1 for password hashing. However, it doesn’t matter whether you enable or disable server-side password hashing as clients send new/changed passwords to XMPP servers in cleartext. The server logs the cleartext password before hashing it.
Your comparison to WPA isn't quite an analogy - in the case of WPA the access point has already selected the password for the network, only authentication is needed. For XMPP and other services, the user selects their own password. This step is where the password is sent (once) to the server, upon which it is hashed and stored. That step doesn't happen in WPA, however the owner of the access point does have to securely transmit the password to the clients somehow.