Oracle 5.0 Reference Manual page 587

+-------------------------+------------------------+
1 row in set (0.00 sec)
mysql> CREATE USER 'newuser'@'localhost' IDENTIFIED BY 'newpass';
Query OK, 0 rows affected (0.03 sec)
mysql> SET PASSWORD FOR 'existinguser'@'localhost' = PASSWORD('existingpass');
Query OK, 0 rows affected (0.00 sec)
The following scenarios are possible in MySQL 4.1 or later. The factors are whether the
column is short or long, and, if long, whether the server is started with
or disabled.
Scenario 1: Short
Password
• Only short hashes can be stored in the
• The server uses only short hashes during client authentication.
• For connected clients, password hash-generating operations involving the
function or password-generating statements use short hashes exclusively. Any change to an
account's password results in that account having a short password hash.
• The value of
old_passwords
generates only short password hashes anyway.
This scenario occurs when a pre-4.1 MySQL installation has been upgraded to 4.1 or later but
has not been run to upgrade the system tables in the
mysql_upgrade
recommended configuration because it does not permit use of more secure 4.1 password hashing.)
Scenario 2: Long
Password
• Short or long hashes can be stored in the
• 4.1 and later clients can authenticate for accounts that have short or long hashes.
• Pre-4.1 clients can authenticate only for accounts that have short hashes.
• For connected clients, password hash-generating operations involving the
function or password-generating statements use short hashes exclusively. Any change to an
account's password results in that account having a short password hash.
In this scenario, newly created accounts have short password hashes because
[480]
old_passwords=1
a long hash before setting
[480]
old_passwords=1
security benefits of a longer hash.
To create a new account that has a long password hash, or to change the password of any existing
account to use a long hash, first set the session value of
the global value set to 1, as described previously.
In this scenario, the server has an up to date
password hashing method set to generate pre-4.1 hash values. This is not a recommended
configuration but may be useful during a transitional period in which pre-4.1 clients and passwords
are upgraded to 4.1 or later. When that has been done, it is preferable to run the server with
[480]
old_passwords=0
Scenario 3: Long
Password
• Short or long hashes can be stored in the
• 4.1 and later clients can authenticate using accounts that have short or long hashes.
Keeping Passwords Secure
column in user table:
Password
[480] is irrelevant because with a short
column; server started with
Password
prevents generation of long hashes. Also, if you create an account with
[480]
old_passwords
results in the account being given a short password, causing it to lose the
Password
and [490].
secure_auth=1
column; server started with
Password
567
old_passwords
column.
Password
mysql
old_passwords=1
column.
to 1, changing the account's password while
old_passwords
column, but is running with the default
old_passwords=0
column.
Password
[480] enabled
[956]
PASSWORD()
column, the server
database. (This is not a
[480]:
[956]
PASSWORD()
[480] set to 0 while leaving
[480]: