Password length is printed in log file (with debug severity)

[inikulshin]

Describe the bug

****

rabbit_log:debug("Asked to create a new user '~ts', password length in bytes: ~tp", [Username, bit_size(Password)]),

Imho, it's not secure.

Reproduction steps

1. Enable debug with rabbitmqctl set_log_level debug
2. Add user in http://localhost:15672/#/users
3. Read log file

Expected behavior

No information about passwords in log file.

Additional context

RabbitMQ 3.12.10

[michaelklishin]

No plans to change anything about it. Logging password length and only at debug level sounds very reasonable to me. RabbitMQ nodes do not log at debug level by default, the operator must opt in.

The LDAP has not one but two logging modes dedicated to debugging. They are complete life savers for LDAP users every so often. They would not be able to debug their system without taking a traffic capture, something that can be effectively impossible for some teams and environments.

[michaelklishin]

The length is logged in response to support cases where it took a long time to debug a password input issue (e.g. a shell-significant character like # without escaping cuts the actual value passed on to CLI commands short).

If you cannot accept a password length being logged at debug level, don't use password-based authentication. Nothing is logged about OAuth 2 tokens or x.509 certificates.

[inikulshin]

Ok... (Maybe password_hash is enough or even better for debugging purpose? For one who knows the password(s) and hashing algorithm, password_hash provides more exact and more secure information.)

But at least synchronize bytes/bits:
password length in bytes: ~tp", [Username, bit_size(Password)]

It may save a life :)

[michaelklishin]

Looks like one other suggestion originally filed as an issue did not make it into a discussion.

It has to do with user connections not being closed after a password change. Deleting the user will close all of its connections, that's what we recommend for emergency credential rotation.

OAuth 2 is another option that has credential expiration as a fundamental idea. Finally, there is x.509 certificate-based authentication with the trust store plugin, that is sits in between,
certificates expire. With the trust store, revoking credentials is comparable to deleting a user.

[inikulshin]

@michaelklishin in this case, imho, preserving connections on password change should be more documented (Btw, where can I read about your recommendations for emergency credential rotation? Isn't closing all user's connections enough?).

I understand and accept the reasons you implemented it this way, but this behavior still seems surprising (or at least far from 100% sure to suppose) to me. Especially when it is different for amqp and http connections.

It's not such a big difference, but connections with "auth_mechanism": "PLAIN" remain open also after user password is changed to No password.

[michaelklishin]

Revoking User Access

[michaelklishin]

I have forgotten that in modern versions there are

rabbitmqctl close_all_user_connections
rabbitmqctl close_all_connections

that both can be used after rabbitmqctl change_password.

[inikulshin]

Closing connections after password change may be not 100% reliable.

In our tests I changed user password immediately after creating some shovels with user:oldPassword
After changing password I tried to use (GET /api/connections).Where(c => c.UserName == username).ForEach(c => DELETE /api/connections/c.Name), but there were still some unexpected shovel connections after that.

It feels like shovel connection creation process passed user password validation step before password change, but the connection is still not in the list of all connections at the time of GET /api/connections.

* Maybe rabbitmqctl works differently.

[michaelklishin]

Shovels take time to start. They also will try to restart indefinitely when whey fail to connect, using the same credentials every time.

If you rotate a user's credentials and that user is used by some Shovels or Federation links, you must re-create the Shovels (or federation upstreams).

There is no password validation for Shovels, of any kind. If you create a user and immediately try to create some Shovels programmatically, it's on you to make sure the user is successfully created before you try to use it.

I don't see how this question has anything to do with the original question.