-
Notifications
You must be signed in to change notification settings - Fork 3.9k
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
Comments
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. |
Password hashing can use any function, it's a matter of implementing a new single function module. |
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 |
I don't have an opinion on whether the implementation in |
Even though this is not a public API we have CI coverage should it ever go away Related to rabbitmq/rabbitmq-server#3350
OTP 24 has 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. |
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.
The text was updated successfully, but these errors were encountered: