The secure_auth variable blocks connection attempts from clients using accounts with old passwords, stored in the format used before MySQL 4.1.

if your database configuration doesn’t use this option don’t change it. This is a deprecated variable and the default settings are the recommended ones.

The goal of this variable is to ensure the MySQL server accepts connections from clients using an account with proper security.

An incorrect usage of this option may degrade the security of connections to the database.


Disabling secure_auth will allow connections from clients using an account with password a format used before MySQL 4.1. MySQL 4.0 reached EOL at December 31, 2008. A database server shouldn’t accept connections from clients trying to use unprotected accounts.

The hashing method used to store passwords from those older accounts in the database is weak, producing 16 bytes hashes.

The first step is to investigate if any of the current clients are using one of those accounts. If such clients also use an outdated version, update those client versions to the most recent compatible with the server version. Create new accounts to those clients, this will ensure their passwords are securely stored.

Despite being possible to use the same password as before, consider using a new one. After all the database stored this password with a weak hash function.

After making sure all clients are up to date, turn on the secure_auth option by deleting the line that turns it off.

Search which configuration file define the option value:

# Look every .cnf file at /etc/mysql and subdirs
grep secure_auth /etc/mysql/{,**/}*.cnf

The output of the command above will point to the culprit file:

/etc/mysql/mysql.conf.d/mysqld.cnf:secure_auth = 0

In the example above the issue is at /etc/mysql/mysql.conf.d/mysqld.cnf

Open the discovered file with your favorite text editor and delete the file that overrides the variable value.

Restart the database server to apply the configuration changes.