Backup traffic After securing application-to-database and replication traffic, you should also do the same for backup traffic. If you use Percona XtraBackup with streaming than you should use SSH to send your backup to a secure location. The same is true for MySQL Enterprise Backup. Also both have options to encrypt the backup itself. If you send your backup to a cloud service this is something you should really do, especially if it is not sent via SSH or HTTPS. And mysqldump and mysqlbinlog both support SSL. And you could use GnuPG, OpenSSL, WinZIP or any other tool to encrypt it. Sending credentials You could try to force the client to send credentials elsewhere. This can be done if you can control the parameters to the mysql client. It reads the config from /etc/my.cnf, ~/.my.cnf and ~/.mylogin.conf but if you for example specify a login-path and a hostname.. it connects to that host, but with the password and username from the loginpath from the encrypted ~/.mylogin.cnf file. ...

The mysql_sha256_password doesn't use the nonce system which is used for mysql_new_password , but instead forces the use of RSA or SSL. This is how that works: The client connects The server changes authentication to sha256 password (or default?) The server sends the RSA public key. The client encrypts the password with the RSA public key and sends it to the server. The server decrypts the password with the private key and validates it. The problem is that the client trusts public key of the server. It is possible to use --server-public-key-path=file_name . But then you need to take care of secure public key distribution yourself. So if we put a proxy between the client and the server and then have the proxy sent its own public key... then we can decrypt it and reencode it with the real public key and send it to the server. Also the decrypted password is the password, not a hash. So we then know the real password. And if SSL is used it doesn't do the RSA encryption....