@carlhoerberg with the tip of stable at least, I can't reproduce with the following steps:

• Start a 3.5.7 node, add a user server-623 with password "server-623"
• Tag the user as administrator
• Stop the node, copy its database directory to /tmp/3.5.7
• Start a 3.6.x node with RABBITMQ_MNESIA_DIR=/tmp/3.5.7
• List users with ets:tab2list(rabbit_user).
• Change password with rabbitmqctl change_password server-623 server-623-new
• Try authenticating with rabbitmqctl authenticate_user server-623 server-623-new (it succeeds)
• Try authenticating with rabbitmqctl authenticate_user server-623 server-623 (it fails)

Are the steps I take different from yours?

Some digging with

git diff rabbitmq_v3_6_0..stable -- src/rabbit_auth_backend_internal.erl
git blame -- src/rabbit_auth_backend_internal.erl

suggests it was fixed in f1f28ea by @hairyhum.

Assigning to @hairyhum because he fixed the issue as part of rabbitmq/rabbitmq-management#117.

I think it would be good to add a test for this, since this caused breakage for our Heroku app, after updating to 3.6.0 and using our managed rabbitmq instance's "rotate password" feature.

Shall I file a new issue for adding the test?

Many thanks :-)

@edmorley I'm afraid adding a test that uses two different database schemas (from 3.5.x and 3.6.0) is going to be quite hard.

The best I can think of is manually injecting a user with a non-standard password hashing function. I have no objections to having an issue for that.