mysql.sql
user_table.zip
[MDEV-17789] Wrong "has a password in the old format" message Created: 2018-11-21 Updated: 2018-11-23 Resolved: 2018-11-23 |
|
| Status: | Closed |
| Project: | MariaDB Server |
| Component/s: | Authentication and Privilege System |
| Affects Version/s: | None |
| Fix Version/s: | N/A |
| Type: | Bug | Priority: | Major |
| Reporter: | Daniel Marschall | Assignee: | Sergei Golubchik |
| Resolution: | Not a Bug | Votes: | 0 |
| Labels: | None | ||
| Attachments: |
mysql.sql
user_table.zip
|
| Description |
|
Environment: Steps to reproduce: Expected result: (happens to all other non-existing users) Actual result: (happens only for the non-existing user "affiliflex") Notes: 1. The message comes from the mysql_native_password plugin. 2. It only works with this exact data and with this non-existing user "affiliflex". (Any other user will result in the normal "access denied" message) If you add or remove any single row in the users table, the bug disappears. If you change the length of any other username in the table, the bug disappears too. If you change the password of the user "1234567890" to a secure password, the bug disappears too. I think there is some kind of hash conflict, since it only works with this specific data. 3. I could reproduce this bug on three completely different Debian 9 systems. One of these systems was completely installed from scratch, with only MariaDB installed, and nothing else. 4. The root password is "hello", just in case you need it |
| Comments |
| Comment by Sergei Golubchik [ 2018-11-23 ] | |
|
This is intentional. Your user table has an entry that with the old password:
So the error "password in the old format" is real and will happen for 1234567890@localhost user. When you try a non-existent user, the server must avoid giving away any information that the user is non-existent. Not only should it not say "Non-existent user", it cannot always say "Access denied" either — for example if all your real users would have passwords in the old format, then "Access denied" would be a clear indicator that a user does not exist. And "password in the old format" would be a clear indicator that a user does exist. MariaDB, instead, uses the same error message for non-existent users that it would use for existent users. With the same ratio. Meaning, if you'll try a million random user names with your user table, you'll get "access denied" in about 98% of cases and "password in the old format" in about 2% of the cases. The same percentage both for existing and non-existing user names, so the error message does not leak any information about what user names exist. | |
| Comment by Sergei Golubchik [ 2018-11-23 ] | |
|
By the way, you're right — the decision what error message to return is based on the hash of the user name and the number of rows in the user table. If you change the number of rows in the table, it'll disappear for this non-existent username, but, of course, will show up for some other non-existent username. | |
| Comment by Daniel Marschall [ 2018-11-23 ] | |
|
Thank you very much for your reply. So, do I understand correctly, that there is indeed a hash conflict? May I ask which hash function you are using, which results in a 2% change of conflicts? (Maybe this could be improved by using a better hash function?) The wrong error message, which was only shown for the non-existing user "affiliflex" but not for every other non-existing user I have tried, confused me very much and I searched for hours, because I was afraid there was some kind of leftovers of that user "affiliflex" which I had deleted ages ago. | |
| Comment by Sergei Golubchik [ 2018-11-23 ] | |
|
You've misunderstood. This is not a bug, the error message is not wrong, and there is no conflict. You have 40 rows in the user table with the new password and one row with the old password. Which means, that for one randomly selected user there's 40/41 ≈ 98% chance to get a new password and 1/41 ≈ 2% chance to get an old password. |