#1560 Login fails if password contains special chars
If I set my password to
I’m unable to login with Dino (uses SCRAM-SHA1) and both Conversations and Gajim after forcing them to use PLAIN. Conversations and Gajim work fine when they connect using SCRAM-SHA1 but only because they have the same bug I believe.
Conversations up to and including 2.8.3 does not saslprep the password before hashing it.
If I start doing that it fails to login with Prosody.
However ejabberd wants me to saslprep the password beforehand.
To be honest I don’t know for sure which one is correct.
RFC 5802 (SCRAM) §2.2 states that the client MUST SASLprep the password before putting it into SCRAM <https://tools.ietf.org/html/rfc5802#section-2.2>:
o Normalize(str): Apply the SASLprep profile [RFC4013] of the
"stringprep" algorithm [RFC3454] as the normalization algorithm to
a UTF-8 [RFC3629] encoded "str". The resulting string is also in
UTF-8. When applying SASLprep, "str" is treated as a "stored
strings", which means that unassigned Unicode codepoints are
prohibited (see Section 7 of [RFC3454]). Note that
implementations MUST either implement SASLprep or disallow use of
non US-ASCII Unicode codepoints in "str".
RFC 5802 §5.1 <https://tools.ietf.org/html/rfc5802#section-5.1> states that the client SHOULD normalise the user name, while allowing for unassigned codepoints:
Before sending the username to the server, the client SHOULD
prepare the username using the "SASLprep" profile [RFC4013] of
the "stringprep" algorithm [RFC3454] treating it as a query
string (i.e., unassigned Unicode code points are allowed). If
the preparation of the username fails or results in an empty
string, the client SHOULD abort the authentication exchange
(*) An interactive client can request a repeated entry of the
RFC 4616 (PLAIN) <https://tools.ietf.org/html/rfc4616> states that normalisation is business of the server side:
Upon receipt of the message, the server will verify the presented (in
the message) authentication identity (authcid) and password (passwd)
with the system authentication database, and it will verify that the
authentication credentials permit the client to act as the (presented
or derived) authorization identity (authzid). If both steps succeed,
the user is authenticated.
The presented authentication identity and password strings, as well
as the database authentication identity and password strings, are to
be prepared before being used in the verification process. The
[SASLPrep] profile of the [StringPrep] algorithm is the RECOMMENDED
preparation algorithm. The SASLprep preparation algorithm is
recommended to improve the likelihood that comparisons behave in an
expected manner. The SASLprep preparation algorithm is not mandatory
so as to allow the server to employ other preparation algorithms
(including none) when appropriate. For instance, use of a different
preparation algorithm may be necessary for the server to interoperate
with an external system.
Thanks for the report.
Looks like there's missing saslprep on passwords in some cases, notably on password change (includes account creation) before the password is run trough PBKDF2.
Thus any password set from prosodyctl or similar would remain unprepped into the hashed form, while if a client applied saslprep during in-band registration or in-band password change then that too would follow into the hash.