What happens when Website Design Company export some users from a previous database where the password is case insensitive into 11G? The case-insensitive passwords in these accounts remain case insensitive, even if the 11G system has turned on password case sensitivity. This makes sense because otherwise old users may not be able to log on from a previously working script or client program. This, however, will change when the user changes his or her password. You can find users who have case sensitive or case insensitive passwords by querying the DBA_USERS view. The PASSWORD_VERSIONS column in this view indicates the release in which the password was created. For example: SELECT USERNAME, PASSWORD_VERSIONS FROM DBA_USERS; USERNAME PASSWORD_VERSIONS ------------------------------ ----------------- JONES 10G 11G ADAMS 10G 11G CLARK 10G 11G PRESTON 11G BLAKE 10G The passwords for accounts jones, adams, and clark were originally created in Release 10g and then reset in Release 11g. Their passwords, assuming case sensitivity has been enabled, are now case sensitive, as is the password for preston. However, the account for blake is still using the Release 10g standard, so it is case insensitive. Once he changes his password, it will become case sensitive and more secure. Users' passwords in Oracle 11G database become case sensitive by default. Regular user and SYSDBA/SYSOPER user's password case sensitivity can be controlled independently. If you have a script with inconsistent password cases, the script may stop working with 11G even though it works fine with previous releases. To learn more about this topic, read "Security Guide".
|