Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

RabbitMQ should support pbkdf2 for password hashing #3350

Open
EricLin89 opened this issue Aug 31, 2021 · 5 comments · May be fixed by #12232
Open

RabbitMQ should support pbkdf2 for password hashing #3350

EricLin89 opened this issue Aug 31, 2021 · 5 comments · May be fixed by #12232
Assignees

Comments

@EricLin89
Copy link

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
Copy link
Contributor

lhoguin commented Aug 31, 2021

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 michaelklishin changed the title RabbitMQ should support pbkdf2 for password hashing by default RabbitMQ should support pbkdf2 for password hashing Aug 31, 2021
@michaelklishin
Copy link
Member

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

@polaris-alioth
Copy link
Contributor

polaris-alioth commented Dec 1, 2021

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
Copy link
Member

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.

@lukebakken lukebakken self-assigned this Oct 24, 2022
lukebakken added a commit to rabbitmq/credentials-obfuscation that referenced this issue Oct 25, 2022
Even though this is not a public API we have CI coverage should it ever go away

Related to rabbitmq/rabbitmq-server#3350
@iinuwa iinuwa linked a pull request Sep 6, 2024 that will close this issue
12 tasks
@iinuwa
Copy link

iinuwa commented Sep 6, 2024

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

6 participants