RabbitMQ should support pbkdf2 for password hashing

[EricLin89]

Currently by default, RabbitMQ only supports sha256 and sha512 for password hashing. These two hasing algorithms are considered having security risks nowadays. The pbkdf2 algorithm is considered more secure and is widely use. Maybe RabbitMQ should support it by default instead of letting users develop their own plugin, since erlang does not have implement pdkdf2 hashing, and many users who use RabbitMQ don't have the ability to implement it by their own.

[lhoguin]

This might be of interest: https://github.com/erlang/otp/blob/master/lib/public_key/src/pubkey_pbe.erl#L102

We use an earlier implementation of this function in https://github.com/rabbitmq/credentials-obfuscation/blob/master/src/credentials_obfuscation_pbe.erl to generate a key that is then used to encrypt/decrypt passwords in a PBE context.

We have not yet looked into using pbkdf2 for password hashing and I don't know if we can reuse the code we already have for that purpose but if we can I think this would be a painless and welcome addition.

[michaelklishin]

Password hashing can use any function, it's a matter of implementing a new single function module.

[polaris-alioth]

We also have the same requirement, providing an new function module is a good idea. If you don't have any time to do this, I would like to do this. @michaelklishin pbkdf2 function is implemented in credentials-obfuscation, or maybe we can use the other pbkdf2 module

[michaelklishin]

I don't have an opinion on whether the implementation in credentials_obfuscation can/should be reused. credentials_obfuscation is a dependency of rabbit_common, not rabbit but effectively always available to the latter.

[iinuwa]

OTP 24 has crypto:pbkdf2_hmac/5 built in, which can be used for this.

I have a draft working locally (#12232), but I am curious about performance problems. PBKDF2 is intentionally computationally expensive, so evaluating the password should be done infrequently. Typical use for password hash algorithms on the web is to validate the user's password once, and then use a long(er)-lived session ID to identify the user for subsequent requests.

From what I understand, on AMQP, password evaluation should only be done at connection time, which, if long-lived, shouldn't be a problem. But the Management UI seems to re-evaluate the password for every single API call on every page load. I think this would be pretty expensive, and if this feature were released, it should come with a caveat that it will cause performance issues if used with the Management UI, or any other context where frequent API calls are being made or new connections are being created.