Authentication mechanism downgrade attack
If the server specifies following SASL authentication mechanism:
<mechanism>DIGEST-MD5</mechanism> <mechanism>PLAIN</mechanism> <mechanism>SCRAM-SHA-1</mechanism> <mechanism>SCRAM-SHA-1-PLUS</mechanism>
The authentication in Gajim will proceed with SCRAM-SHA-1-PLUS mechanism, if this fails the authentication will proceed with SCRAM-SHA-1 mechanism, then DIGEST-MD5 and if this fails finally PLAIN.
During the last PLAIN authentication the password will be send as plain text.
This behavior defeats the whole purpose of DIGEST-MD5, SCRAM-SHA-1, SCRAM-SHA-1-PLUS mechanisms.
The purpose of DIGEST-MD5, SCRAM-SHA-1, SCRAM-SHA-1-PLUS mechanisms is to not send password as plain text. If an active attacker can affect the authentication by modifying the data in DIGEST-MD5, SCRAM-SHA-1 authentication, or simply by disabling DIGEST-MD5, SCRAM-SHA-1, SCRAM-SHA-1-PLUS methods, he can get the password.
Any entity that will act as a SASL client or a SASL server MUST maintain an ordered list of its preferred SASL mechanisms according to the client or server, where the list is ordered according to local policy or user configuration (which SHOULD be in order of perceived strength to enable the strongest authentication possible). The initiating entity MUST maintain its own preference order independent of the preference order of the receiving entity. A client MUST try SASL mechanisms in its preference order. For example, if the server offers the ordered list "PLAIN SCRAM-SHA-1 GSSAPI" or "SCRAM-SHA-1 GSSAPI PLAIN" but the client's ordered list is "GSSAPI SCRAM-SHA-1", the client MUST try GSSAPI first and then SCRAM-SHA-1 but MUST NOT try PLAIN (since PLAIN is not on its list).
It should be possible to disable weak authentication mechanisms such as DIGEST-MD5, PLAIN in Gajim.