Oracle 5.0 Reference Manual page 586

• Pre-4.1 client authenticating with short password hash
• 4.1 or later client authenticating with short password hash
• 4.1 or later client authenticating with long password hash
The way in which the server generates password hashes for connected clients is affected by the width
of the column and by the
Password
generates long hashes only if certain conditions are met: The
to hold long values and
Those conditions apply as follows:
• The column must be wide enough to hold long hashes (41 bytes). If the column has not
Password
been updated and still has the pre-4.1 width of 16 bytes, the server notices that long hashes cannot
fit into it and generates only short hashes when a client performs password-changing operations
using the
PASSWORD()
that occurs if you have upgraded from a version of MySQL older than 4.1 to 4.1 or later but have not
yet run the
mysql_upgrade
• If the column is wide, it can store either short or long password hashes. In this case, the
Password
[956] function and password-generating statements generate long hashes unless
PASSWORD()
the server was started with the
generate short password hashes instead.
The purpose of the
old_passwords
pre-4.1 clients under circumstances where the server would otherwise generate long password hashes.
The option does not affect authentication (4.1 and later clients can still use accounts that have long
password hashes), but it does prevent creation of a long password hash in the
of a password-changing operation. Were that permitted to occur, the account could no longer be used
by pre-4.1 clients. With
• An old pre-4.1 client connects to an account that has a short password hash.
• The client changes its own password. With
account having a long password hash.
• The next time the old client attempts to connect to the account, it cannot, because the account has
a long password hash that requires the 4.1 hashing method during authentication. (Once an account
has a long password hash in the user table, only 4.1 and later clients can authenticate for it because
pre-4.1 clients do not understand long hashes.)
This scenario illustrates that, if you must support older pre-4.1 clients, it is problematic to run
a 4.1 or newer server without
[480], password-changing operations do not generate long password hashes and
old_passwords=1
thus do not cause accounts to become inaccessible to older clients. (Those clients cannot inadvertently
lock themselves out by changing their password and ending up with a long password hash.)
The downside of
old_passwords=1
hashes, even for 4.1 or later clients. Thus, you lose the additional security provided by long password
hashes. To create an account that has a long hash (for example, for use by 4.1 clients) or to change
an existing account to use a long password hash, an administrator can set the session value of
[480]
old_passwords
mysql> SET @@session.old_passwords = 0;
Query OK, 0 rows affected (0.00 sec)
mysql> SELECT @@session.old_passwords, @@global.old_passwords;
+-------------------------+------------------------+
| @@session.old_passwords | @@global.old_passwords |
+-------------------------+------------------------+
|
Keeping Passwords Secure
old_passwords
[480]
old_passwords
[956] function or a password-generating statement. This is the behavior
program to widen the
old_passwords
[480] system variable is to permit backward compatibility with
[480]
old_passwords
old_passwords
old_passwords
[480] is that any passwords created or changed use short
set to 0 while leaving the global value set to 1:
0 |
566
[480] system variable. A 4.1 or later server
Password
must not be set to 1.
column.
Password
[480] system variable set to 1 to force the server to
disabled, the following undesirable scenario is possible:
[480] disabled, this results in the
[480] set to 1. By running the server with
1 |
column must be wide enough
table as the result
user