If I set my password to 2ø'±s;ßà¼Å 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 username value. 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.

• tags Status-Accepted

Started.

• tags Status-Started Milestone-0.11
• owner Zash

Fixed in https://hg.prosody.im/0.11/rev/646af16a3f32 followed by some additional commits that should ensure saslprep is applied everywhere a password enters the system. Please test.

• tags Status-Fixed