Re: ERROR 1045 (28000): Access denied for user 'MyUser'@'localhost' (using password: YES)
Posted by: Filipe Silva
Date: March 25, 2021 02:18PM

Hi Roger,

1. Should not have failed because MySQL connections are secure by default. This may happen if you don't have TLS/SSL keys and certificates properly configured in the server or if you are disabling ssl in some options file that is being loaded by the mysql client tool.

Alternatively to requiring a secure connection, you can establish TCP-based connections to MySQL given that you have configured a pair of RSA keys on the server and you start the client with the option `--get-server-public-key`.

2. Connecting through a Unix Socket requires you to be physically on the machine where MySQL server is running. This is considered a secure environment and this is why in this case you don't need any kind of encryption.

3. Correct. Once the user credentials are cached the user id able to create a connection through a non-secure channel.


Quote

how come this behavior can not be considered a bug ?

This is not a bug because this is exactly how caching_sha2_password authentication is expected to behave.


Quote

if the plugin is serious to reject my connection because it is not secure, I guess is concerned about the password flying cleartext, how come it is allowed the second time, isnt the password flying clear text the second time ?

No, the password is not being sent as clear text the second time. The password is replaced by a hash key, computed at login time, different every time, which only a client that knows the password is able to generate.


Quote

the TCP connection has not being made more secure just because the password got cached through a successful authentication using a secure connection (unix socket), right ?

No, the TCP connection has not become more secure. But now the server knows that this specific user is someone it trusts because of a previous fully-fledged authentication cycle, through a verified secure channel.

Note that if you choose to not encrypt the data in the wire this process only secures your password, not the data. If the channel is secure, then both the clear-text password and the data are safe by its very nature.


Quote

am I making a mistake somewhere ?

Please read the documentation here


Quote

the other thing would be: isnt a tcp connection to 127.0.0.1 as secure as a unix socket connection ?

Well, no. You can do all kinds of network redirections that go through 127.0.0.1, and given that data packets have to run through the TCP stack anything can happen. I mean, the attack surface of a local TCP connection is way larger than a Unix Socket, which basically interconnects two running processes on the same machine.

IHTH

Options: ReplyQuote




Sorry, only registered users may post in this forum.

Content reproduced on this site is the property of the respective copyright holders. It is not reviewed in advance by Oracle and does not necessarily represent the opinion of Oracle or any other party.