> XMPP uses passwords for authentication, rather than phone numbers. Since the server needs to use the password to verify you are you, there should be no surprise that it is sent to the server when you create your account or change your password. Just like any website or service that utilizes passwords for authentication.

There are plenty of authentication protocols that don't send passwords in cleartext. WPA would be rather useless if that happened, for example. Granted, the server operator can impersonate anyone they want already, but password leaks are a thing.

Server-side contact handling is independent of end-to-end ecryption, and doesn't need to be plaintext either.

Pretty much the only excusable things here are what's related to IP.

I believe you're slightly misunderstanding the details here (no surprise, as the article is not clear). All modern XMPP servers store the password securely hashed, and during authentication only hashes are exchanged.

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.

> All modern XMPP servers store the password securely hashed, and during authentication only hashes are exchanged.

Huh, I didn't realize that SCRAM is this widely supported https://xmpp.net/reports.php

Thanks for the hint!

I see the distinction, but when I use public key cryptography, the keys are not symmetrical, and the server never sees my secret.

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?

Yes. You'd probably want to derive your private key from the password, so that you don't have to store anything and use this method portably on multiple computers. But there's no need to ever send a password to the server, even when setting/changing it.

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.

> I believe you're slightly misunderstanding the details here (no surprise, as the article is not clear).

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.

Hi, authors here (Again, as we already have had the pleasure a while ago).

> The main problem with this article is that all the points apply equally to other services, but the article frames it such that it implies the problems are unique to XMPP.

The article never states that these issues exclusively apply to XMPP. In our opinion, users should be aware of these downsides that might be obvious to technical people, but aren't obvious to others.

And no, not all the points apply equally to other services. Even if this would be the case, then should we just withhold downsides of XMPP because these downsides might also apply to unrelated communication protocols? This article is about XMPP, not about something else.

> Pretty much everything else listed is solved by verified end-to-end encryption, which is the primary solution to these problems regardless of any platform or protocol you use.

No, as stated in the article, you can't solve most problems with XMPP by enforcing E2EE in XMPP. This article is about XMPP, not about unrelated communication protocols that might have similar problems.

> Instead of focusing on helping educate people sensibly about these things, the article seems to be a lot of biased scaremongering.

Ehm, no, again, this article lists verifiable downsides of XMPP. People should be aware of these downsides and decide on their own what they want to do. There is no need to call it "biased scaremongering."

> Full disclosure

Full disclosure: We aren't involved in any XMPP projects or any other projects related to instant messaging. No party paid for our article.

> Tools to solve this (e.g. Tor, VPNs) are well known and established solutions if you need to hide your IP from websites and services you use.

So true, yet some clients might still leak information. For example WebRTC leaks in web browsers is a real concern (which is why Tor Browser disables WebRTC entirely, except maybe in unsafe mode?). I also heard some mobile/desktop clients have such leaks when it comes to VOIP, but i didn't try to reproduce yet. This would be worth investigating with wireshark and a couple of volunteers.

> not a problem with XMPP specifically.

There is one problem the author mentioned which applies to XMPP but not to email/ActivityPub: presence tracking. So your own server/admin will know when a client-to-server (c2s) connection is active, but in the XMPP ecosystem it's rather common for clients and servers to advertise the presence status (online, away) to the entire world, and that's a huge metadata leak. Maybe something to investigate in the future.

> There is one problem the author mentioned which applies to XMPP but not to email/ActivityPub: presence tracking. [...] clients and servers to advertise the presence status (online, away) to the entire world, and that's a huge metadata leak.

They don't advertise it to the entire world, but to authorized contacts (and typically groups that you join). With the rise of mobile clients, statuses other than 'online' are far less common than they used to be, because they are growing irrelevant.

Advertising online status to the whole world is what WhatsApp does ( https://news.ycombinator.com/item?id=26809770 ).

> and typically groups that you join

So more or less to the entire world if you join public chats. Even if you use different nicknames, occupant-id (used for message edits) may be used to track your presence across rooms.

> Advertising online status to the whole world is what WhatsApp does

If we're pointing the finger, i'd recommend reading this document about what Signal does wrong in terms of privacy and security. It's overall a good read of what not to do in private messenger UX:

https://north-shore.info/wp-content/uploads/2019/06/signalfa...

>They don't advertise it to the entire world, but to authorized contacts (and typically groups that you join)

But in the article they showed how the server administrator can easily add contacts to a user's contact list. So my understanding is that the user isn't really in control of who can see this information, as the server admin could add a new contact that can then see the presence status. Correct?

Edit: formatting

Valid question, not sure why the downvotes. You're right, the server can modify the contact list (and this is used extensively within organizations, and in Snikket to ensure family members can see each other by default).

But this isn't the cause for concern here - if the server is malicious it can broadcast this info without the need to modify your contact list. This again is independent of protocol - if someone wants to log or share the times and durations you are actively connected to their server, they can do so quite easily. It doesn't require XMPP.

> the user isn't really in control of who can see this information

Server-side parties (e.g., the admin) can see the status information without adding somebody to the group. It is in cleartext, passing the server.

Strange criticism. Advertising presence information is the _goal_ of XMPP protocol. The "P" in XMPP stands for Presence.

Indeed! However, some things have changed since XMPP initially came out. For example, Message Archive Management (and equivalents in the PubSub/MIX specs) has been introduced so that messages can be stored reliably, reducing the need for presence. Multi-client usage has also grown, especially with mobile computers ("smartphones") with Internet access everywhere. Then, we now know and have proof that metadata leaks are used to actually harm people and that presence information can be used to establish correlations between several identities.

To be clear, I'm not arguing against presence being supported on a protocol level. However, i believe the protocol and clients/servers should support the usecase where presence information should not be leaked: that people see a message when i send it is fine, but that they know when my computer is online/offline, or when i'm "away" is way too much metadata leak for a privacy-conscious usecase.

My favorite way to deal with that would be to have a "private browsing" mode on IM clients. So that you could turn on/off privacy settings globally with a single switch. I'm guessing a lot of people would choose the "private" mode if prompted for it on first run. I know i would :)

It is quite possible not to send presence information at all. I'll say more, we're working on an 'omnipresence' protocol that will advertise only the desired status to the external contacts, and will not leak per-device presences.

This Presence thing works well for always connected clients (desktop), but becomes a huge problem on clients that can't be always connected (iOS ones).

Desktop is not always connected. People turn it off, or suspend it to save on electricity bills.

From the point of view of xmpp development, it is always connected. Thing is, xmpp session start is a very costly operation. Desktop generally does it once and has it easy from then on. iOS device connects every time a user opens an app. By the time it'll finish receiving presence information, a user will already close it, and the OS will terminate app process.

Unless the protocol is connectionless, the server will always know at least the user's online status.

I have to use Slack for work, and the way I solve this is to have my client not send typing notifications, and have the client running on my server and repeatedly sending activity notifications all the time, so I always appear online and present to Slack servers.

I can prevent Slack from knowing when I'm really connected only by being connected all the time and always pinging my activity status in periodic fashion 24/7, so that from PoV of the server it's not possible to determine anything about my actual activity or online status on my workstation, because there's no relation to real-life status.

Would these leaks be solved by implementing a VPN at the router instead of the host?