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