Auditing an Oracle database for security issues is very important. PeteFinnigan.com provides all of the information and tools that you will need Click here for details of PeteFinnigan.com Limited's detailed Oracle database security audit service Click here for details of PeteFinnigan.com Limited's Oracle Security Training Courses
There are 39 visitors online    
Cookie Policy:We only use essential cookies on small sections of this website. For details see here.


Back

Passwords transmitted in clear text on SQL*Net for CREATE USER and GRANT ... IDENTIFIED BY statements

This short article comes from a post on the ORACLE-L list by Ravi Kulkarni who pointed out that CREATE USER commands also pass the password to the database server in clear text as well. I did a couple of test cases to check this as follows:

I first set the following values in my server $ORACLE_HOME/network/admin/sqlnet.ora file:

	TRACE_FILE_SERVER=clear_text.trc
	TRACE_DIRECTORY_SERVER=c:\temp
	TRACE_LEVEL_SERVER=SUPPORT					
						

And i connected to SQL*Plus and ran the two following commands to create two users:

	SQL*Plus: Release 9.2.0.1.0 - Production on Mon Mar 15 19:59:27 2004
	
	Copyright (c) 1982, 2002, Oracle Corporation.  All rights reserved.
	
	
	Connected to:
	Personal Oracle9i Release 9.2.0.1.0 - Production
	With the Partitioning, OLAP and Oracle Data Mining options
	JServer Release 9.2.0.1.0 - Production
	
	SQL> create user pete5 identified by pete5;
	
	User created.
	
	SQL> grant create session to pete6 identified by pete6;
	
	Grant succeeded.
	
	SQL> 						
						

These two cases produced the following entries in the SQL*Net trace file:

	[15-MAR-2004 19:59:47:263] nsprecv: 00 00 00 00 00 25 63 72  |.....%cr|
	[15-MAR-2004 19:59:47:263] nsprecv: 65 61 74 65 20 75 73 65  |eate.use|
	[15-MAR-2004 19:59:47:263] nsprecv: 72 20 70 65 74 65 35 20  |r.pete5.|
	[15-MAR-2004 19:59:47:263] nsprecv: 69 64 65 6E 74 69 66 69  |identifi|
	[15-MAR-2004 19:59:47:263] nsprecv: 65 64 20 62 79 20 70 65  |ed.by.pe|
	[15-MAR-2004 19:59:47:263] nsprecv: 74 65 35 01 00 00 00 01  |te5.....|						
						

and

	[15-MAR-2004 20:00:46:648] nsprecv: 00 00 00 00 31 67 72 61  |....1gra|
	[15-MAR-2004 20:00:46:648] nsprecv: 6E 74 20 63 72 65 61 74  |nt.creat|
	[15-MAR-2004 20:00:46:648] nsprecv: 65 20 73 65 73 73 69 6F  |e.sessio|
	[15-MAR-2004 20:00:46:648] nsprecv: 6E 20 74 6F 20 70 65 74  |n.to.pet|
	[15-MAR-2004 20:00:46:648] nsprecv: 65 36 20 69 64 65 6E 74  |e6.ident|
	[15-MAR-2004 20:00:46:648] nsprecv: 69 66 69 65 64 20 62 79  |ified.by|
	[15-MAR-2004 20:00:46:648] nsprecv: 20 70 65 74 65 36 01 00  |.pete6..|
						

These two cases show that the passwords for this syntax are indeed passed in clear text to the server.

What can we do to prevent a hacker or malicious employee taking advantage of this? A few options spring to mind

  • use encrypted network connections such as Oracle's Advanced Security Option or free solutions such as tunneling with ssh.
  • Set the password to "password" or something similar but importantly set the account to be locked and expired as well. Then the password can be changed using the PASSWORD function in SQL*plus that doesn't transmit the password in clear text.

Please see also Passwords in clear text for ALTER USER in SQL*Net and Issues with bypassing password protected roles for info on similar issues.



Back