Skip to content

Archive for

Oracle impossible passwords, why?

When you configuring the password for a user in database, it automatically calculating the password hash normally or bypassing the hash process and writing a value to the PASSWORD column of sys.user$.

Just a exmple :

SQL> create user imppassword identified by imppassword;

User created.

SQL> select name,password from sys.user$ where name='IMPPASSWORD';

NAME                           PASSWORD

------------------------------ ------------------------------

IMPPASSWORD                    27D780816A86DC5C

When this user provides their credentials to Oracle to log in, Oracle will take the credentials, create the password hash, and then compare it with the value stored in SYS.USER$, find a match, and allow the user to connect.

SQL> grant connect,resource to imppassword;

Grant succeeded.

SQL> conn imppassword/imppassword;


If we created the user and explicitly set the password value, things would be different.

SQL> create user password identified by values 'password';

User created.

SQL> grant connect,resource to password;

Grant succeeded.

SQL> select name,password from sys.user$ where name = 'PASSWORD';

NAME                           PASSWORD

------------------------------ ------------------------------

PASSWORD                       password

This time the value stored is the text string PASSWORD.This is an impossible password, because regardless of the input, the Oracle password hashing algorithm could never produce output that matches. Now you can not able to log in this user. Its called impossible password.

Why it need for implement?

If you would like to lock the user account, The attacker tries to login the these user account it shows the user account is locked , they may get a good information from this error.  Locking default accounts tells an attacker what schemas and therefore what features are installed on a given database.This allows them to create a plan of attack before they ever penetrate the database, building a list of potential exploits with the benefit of knowing which potentially vulnerable features are installed.

SQL> conn scott/tiger

ERROR: ORA-28000: the account is locked

Warning: You are no longer connected to '


Furthermore, the attacker now knows the password for each account is set to the default value! Setting an impossible password and unlocking the accounts prevents an attacker from logging in, but also provides no information about the existence of each account/schema or their password.

SQL> conn password/password

ERROR: ORA-01017: invalid username/password; logon denied

Warning: You are no longer connected to ORACLE.

With impossible passwords, an attacker gets no information from an attempt to log in to the database with each default account and password. Less information is always better and it’s our responsibility to make a hacker’s job as difficult as possible.