Question of the day: Did any one, ever use "password" as the secret password? If you never played with the passwords, dont worry. Oracle has a password game you can play. At one level, the rounds are easy, but in the bonus round, the game gets harder. The easy rounds occur when you use Oracle's own password function and external authentication. "Passwording" becomes more difficult when you use or implement advanced security features.
Passwording the regular way
There is not a lot to say about "create user scott identified by tiger," or is there? Can you break the 16-character hashed value of "F894844C34402B67?"
SQL> select username, password
2 from dba_users;
USERNAME PASSWORD
-------- -------------------
SYS 8A8F025737A9097A
SYSTEM D4DF7931AB130E37
DBSNMP ` E066D214D5421CCC
SCOTT F894844C34402B67
SH 54B253CBBAAA8C48
HR 4C6D73C3E8B0F0DA
If you could, what a major security flaw that would be! Aside from poor personal security, (a user leaving his password under the keyboard, or using something easily guessed that is personal in nature), your only real option in cracking an Oracle-generated password is via a brute force attempt (more on that in just a bit).
Can you reverse engineer the process or function Oracle uses? "Aha! I'll turn on tracing and capture the "create user" (or "alter user") statement." Let's see if that works. We will turn on tracing, issue the alter user statement, and then turn off tracing.
SQL> alter session set sql_trace = true;
Session altered.
SQL> alter user scott identified by lion;
User altered.
SQL> alter session set sql_trace = false;
Session altered.
An extract from the trace file is shown below.
=====================
PARSING IN CURSOR #1 len=35 dep=0 uid=5 oct=43 lid=5
tim=1946713635851 hv=3135717156 ad='66f0bc08'
alter user scott identifi
END OF STMT
PARSE
Note the line from the trace file, where it shows "alter user scott identifi." Oracle truncates the statement so you cannot see the complete statement. So much for that idea.
What about creating another user and use the same password?
SQL> create user shyam identified by lion;
User created.
SQL> select username, password
2 from dba_users
3 where username='SHYAM';
USERNAME PASSWORD
-------- ------------
SHYAM DA46FC0F06BCECEA
Even though Scott and Shyam share the same password, the hashed values are entirely different.
If you are new to Oracle, one topic or trick you should research is the "identified by values" option. As a DBA (or other privileged user), how would you log in as a user should the need arise? You can take the 16-character password string and save it off somewhere, issue an alter user statement where you create a new password, log in as the user, and then reset the user's password with
SQL>alter user username identified by values 'the 16-character string from before';
What about a brute force attack on cracking an Oracle password? Just to pick one program at random off a Google search, the estimated time to crack a password can range from a few moments to well, practically, an infinite amount of time.If a user creates a simple password, the likelihood of a brute force password cracker's success increases. As the DBA, you can encourage users to create difficult to guess passwords, but can you enforce that rule?
Passwording the regular way
There is not a lot to say about "create user scott identified by tiger," or is there? Can you break the 16-character hashed value of "F894844C34402B67?"
SQL> select username, password
2 from dba_users;
USERNAME PASSWORD
-------- -------------------
SYS 8A8F025737A9097A
SYSTEM D4DF7931AB130E37
DBSNMP ` E066D214D5421CCC
SCOTT F894844C34402B67
SH 54B253CBBAAA8C48
HR 4C6D73C3E8B0F0DA
If you could, what a major security flaw that would be! Aside from poor personal security, (a user leaving his password under the keyboard, or using something easily guessed that is personal in nature), your only real option in cracking an Oracle-generated password is via a brute force attempt (more on that in just a bit).
Can you reverse engineer the process or function Oracle uses? "Aha! I'll turn on tracing and capture the "create user" (or "alter user") statement." Let's see if that works. We will turn on tracing, issue the alter user statement, and then turn off tracing.
SQL> alter session set sql_trace = true;
Session altered.
SQL> alter user scott identified by lion;
User altered.
SQL> alter session set sql_trace = false;
Session altered.
An extract from the trace file is shown below.
=====================
PARSING IN CURSOR #1 len=35 dep=0 uid=5 oct=43 lid=5
tim=1946713635851 hv=3135717156 ad='66f0bc08'
alter user scott identifi
END OF STMT
PARSE
Note the line from the trace file, where it shows "alter user scott identifi." Oracle truncates the statement so you cannot see the complete statement. So much for that idea.
What about creating another user and use the same password?
SQL> create user shyam identified by lion;
User created.
SQL> select username, password
2 from dba_users
3 where username='SHYAM';
USERNAME PASSWORD
-------- ------------
SHYAM DA46FC0F06BCECEA
Even though Scott and Shyam share the same password, the hashed values are entirely different.
If you are new to Oracle, one topic or trick you should research is the "identified by values" option. As a DBA (or other privileged user), how would you log in as a user should the need arise? You can take the 16-character password string and save it off somewhere, issue an alter user statement where you create a new password, log in as the user, and then reset the user's password with
SQL>alter user username identified by values 'the 16-character string from before';
What about a brute force attack on cracking an Oracle password? Just to pick one program at random off a Google search, the estimated time to crack a password can range from a few moments to well, practically, an infinite amount of time.If a user creates a simple password, the likelihood of a brute force password cracker's success increases. As the DBA, you can encourage users to create difficult to guess passwords, but can you enforce that rule?
No comments:
Post a Comment