Passwords transmitted in clear text on SQL*Net

This short article comes from a post I made a few days ago to the ORACLE-L mailing list about some security issues with the SYS password and whether it could be hacked easily. One issue discussed was whether passwords are still transmitted in clear text between the client and the server. This is not the case when a connection / authentication takes place. The transmissions since 7.3 have been encrypting the password exchange so there is not a problem there. But if you come to change a password it is a different story.

I did a couple of experiments with changing passwords for users with the old ALTER USER syntax and also with the newer SQL*Plus based password syntax. let's see what happens:

First I ran the following on SQL*Plus:

	SQL> alter user scott identified by tiger;

	User altered.

	SQL>

I also set up SQL*Net trace on the server with the following lines added to the $ORACLE_HOME/network/admin/sqlnet.ora file.

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

This gave me the following interesting lines in the trace file that was generated.

	[10-MAR-2004 12:52:40:567] nsprecv: 74 65 72 20 75 73 65 72  |ter.user|
	[10-MAR-2004 12:52:40:567] nsprecv: 20 73 63 6F 74 74 20 69  |.scott.i|
	[10-MAR-2004 12:52:40:567] nsprecv: 64 65 6E 74 69 66 69 65  |dentifie|
	[10-MAR-2004 12:52:40:567] nsprecv: 64 20 62 79 20 74 69 67  |d.by.tig|
	[10-MAR-2004 12:52:40:567] nsprecv: 65 72 01 00 00 00 01 00  |er......|

Bad news the password is visible in clear text, this is clearly a security risk as it could be sniffed from the network. next we will try the same experiment to change a users password but this time using the password functionality is SQL*Plus. Here is the commands I ran in SQL*Plus:

	SQL> password dbsnmp
	Changing password for dbsnmp
	New password: ******
	Retype new password: ******
	Password changed
	SQL>

Again SQL*Net trace was used and i got the following entry in the trace file:

	[10-MAR-2004 12:53:33:132] nsprecv: 64 62 73 6E 6D 70 10 00  |dbsnmp..|
	[10-MAR-2004 12:53:33:132] nsprecv: 00 00 10 41 55 54 48 5F  |...AUTH_|
	[10-MAR-2004 12:53:33:132] nsprecv: 4E 45 57 50 41 53 53 57  |NEWPASSW|
	[10-MAR-2004 12:53:33:132] nsprecv: 4F 52 44 20 00 00 00 20  |ORD.....|
	[10-MAR-2004 12:53:33:132] nsprecv: 38 39 44 46 45 31 46 36  |89DFE1F6|
	[10-MAR-2004 12:53:33:132] nsprecv: 37 34 43 38 34 36 45 30  |74C846E0|
	[10-MAR-2004 12:53:33:132] nsprecv: 45 39 34 39 43 36 36 30  |E949C660|
	[10-MAR-2004 12:53:33:132] nsprecv: 33 32 33 31 39 32 31 35  |32319215|

Better news!, the password is not displayed in clear text. the number shown is also not the hash seen in the table SYS.USER$.PASSWORD. It must be some sort of session number or possibly the password encrypted for transmission?

What lessons can we learn from this, well two things spring to mind. The first is don't ever change passwords - OK, only kidding on that one!!, If you change passwords then do not use the alter user syntax but instead use the password functionality provided in SQL*Plus. Revoke alter user from all but database admin staff.

The second thing is to try and avoid anyone sniffing the network for clear text password transmissions. How can we do that? One way is to use ssh to encrypt transmissions from an admin PC to the database server. The other option is to use Oracle's advance security option. This is an extra cost item though. One other step to take is to ensure that no one but the owner of the Oracle software can write to the sqlnet.ora file on the server so that they cannot create trace files to capture transmissions such as this one. OK, that would not stop SQL*Net trace being set on the client or the use of network sniffers such as the Unix utility snoop but its better than nothing. Client sqlnet.ora files can be protected by deploying them on a network driver rather than on the users PC. This unfortunately can be bypassed by creating a local file but its a good start. Other than avoiding the use of ALTER USER encrypted network transmissions are really the only option.

Back