Oracle 5.0, Справочное руководство

Страница: 588 / 3232

Keeping Passwords Secure
568
• Pre-4.1 clients can authenticate only using accounts that have short hashes.
• For connected clients, password hash-generating operations involving the
PASSWORD()
[956]
function or password-generating statements use short hashes exclusively. A change to an account's
password results in that account having a long password hash.
As indicated earlier, a danger in this scenario is that it is possible for accounts that have a short
password hash to become inaccessible to pre-4.1 clients. A change to such an account's password
made using the
PASSWORD()
[956] function or a password-generating statement results in the
account being given a long password hash. From that point on, no pre-4.1 client can connect to the
server using that account. The client must upgrade to 4.1 or later.
If this is a problem, you can change a password in a special way. For example, normally you use
SET
PASSWORD
as follows to change an account password:
SET PASSWORD FOR ' some_user '@' some_host ' = PASSWORD('mypass');
To change the password but create a short hash, use the
OLD_PASSWORD()
[956] function instead:
SET PASSWORD FOR ' some_user '@' some_host ' = OLD_PASSWORD('mypass');
OLD_PASSWORD()
[956] is useful for situations in which you explicitly want to generate a short hash.
The disadvantages for each of the preceding scenarios may be summarized as follows:
In scenario 1, you cannot take advantage of longer hashes that provide more secure authentication.
In scenario 2,
old_passwords=1
[480] prevents accounts with short hashes from becoming
inaccessible, but password-changing operations cause accounts with long hashes to revert to short
hashes unless you take care to change the session value of
old_passwords
[480] to 0 first.
In scenario 3, accounts with short hashes become inaccessible to pre-4.1 clients if you change their
passwords without explicitly using
OLD_PASSWORD()
[956] .
The best way to avoid compatibility problems related to short password hashes is to not use them:
• Upgrade all client programs to MySQL 4.1 or later.
• Run the server with
old_passwords=0
[480] .
• Reset the password for any account with a short password hash to use a long password hash.
• For additional security, run the server with
secure_auth=1
[490] .
6.1.2.5. Implications of Password Hashing Changes in MySQL 4.1 for Application
Programs
An upgrade to MySQL version 4.1 or later can cause compatibility issues for applications that use
PASSWORD()
[956] to generate passwords for their own purposes. Applications really should not do
this, because
PASSWORD()
[956] should be used only to manage passwords for MySQL accounts.
But some applications use
PASSWORD()
[956] for their own purposes anyway.
If you upgrade to 4.1 or later from a pre-4.1 version of MySQL and run the server under conditions
where it generates long password hashes, an application using
PASSWORD()
[956] for its own
passwords breaks. The recommended course of action in such cases is to modify the application to
use another function, such as
SHA1()
[956] or
MD5()
[955] , to produce hashed values. If that is
not possible, you can use the
OLD_PASSWORD()
[956] function, which is provided for generate short
hashes in the old format. However, you should note that
OLD_PASSWORD()
[956] may one day no
longer be supported.
If the server is running with
old_passwords=1
[480] , it generates short hashes and
OLD_PASSWORD()
[956] is is equivalent to
PASSWORD()
[956] .