Introduction

If you are creating or updating RabbitMQ users through the Management HTTP API, you usually do not need to generate the password hash yourself. The simplest approach is to send a plain password field and let RabbitMQ hash it, or ask RabbitMQ to generate the hash through its dedicated HTTP endpoint if you explicitly need a password_hash value.

Let RabbitMQ Hash the Password for You

For most automation, send the password directly when creating the user.

1curl -u guest:guest \
2  -H 'content-type:application/json' \
3  -X PUT http://localhost:15672/api/users/app-user \
4  -d '{
5    "password": "s3cret-value",
6    "tags": "management"
7  }'

RabbitMQ hashes and stores the password internally. This is the cleanest option because you do not have to reproduce RabbitMQ's password hashing behavior in your own code.

Use the HTTP API to Generate a Hash When Needed

RabbitMQ also exposes an endpoint that returns the password hash for a supplied password.

curl -u guest:guest \
  http://localhost:15672/api/auth/hash_password/s3cret-value

That returns a hash string you can then use in user-management automation if your workflow requires password_hash rather than plain password.

Send password_hash Explicitly

If you already have the generated hash, you can send it to the user API instead of the raw password.

1curl -u guest:guest \
2  -H 'content-type:application/json' \
3  -X PUT http://localhost:15672/api/users/app-user \
4  -d '{
5    "password_hash": "generated-hash-value",
6    "tags": "management"
7  }'

This is useful in systems where the automation pipeline is not allowed to persist raw passwords after the initial secret material is handled.

Keep the Hashing Algorithm Aligned

RabbitMQ user records also involve a hashing algorithm. If you are providing password_hash yourself, make sure the algorithm and hash value match what the server expects. The safest path is still to let RabbitMQ generate the hash or use its own hash-generation endpoint so the format stays correct.

Trying to reverse-engineer the hash manually is unnecessary when the server already provides an official interface for the job.

Decide Which Workflow You Actually Need

A practical rule is:

• use password when creating users from trusted automation
• use /api/auth/hash_password/... if you specifically need a hash
• send password_hash only when the workflow requires pre-hashed secrets

That keeps the integration simple and avoids cryptographic guesswork in application code.

Protect the Operational Path

Even when RabbitMQ handles the hashing, the raw password still exists briefly in your script, command history, or CI environment. Protect that path carefully:

• avoid shell history leakage
• prefer secrets injection over hard-coded values
• use HTTPS in production
• minimize who can call the management API

Good password handling is not only about hashing. It is also about how the secret moves through your automation.

Prefer Official Interfaces Over Custom Crypto

If the broker already exposes a supported way to hash or accept passwords, use that interface. Security-related integrations are one of the worst places to rely on guessed implementation details.

Common Pitfalls

• Reimplementing RabbitMQ's password hashing manually when the API can do it for you.
• Sending a password_hash that does not match the expected hashing algorithm.
• Assuming password_hash is required for normal user creation.
• Exposing raw passwords in shell history, CI logs, or plaintext configuration.
• Forgetting to secure management API access with proper credentials and transport security.

Summary

• In most cases, send password and let RabbitMQ generate the hash.
• If you need a hash value, RabbitMQ provides an HTTP endpoint to generate it.
• Use password_hash only when your automation specifically requires pre-hashed input.
• Keep the hashing algorithm aligned with RabbitMQ's expectations.
• Protect the full secret-handling path, not just the stored hash.