Why is OS authentication considered poor security for Oracle databases?

Question

Oracle is deprecating OS authentication according to the Oracle Database Security Guide, which says

Be aware that the REMOTE_OS_AUTHENT parameter was deprecated in Oracle Database 11g Release 1 (11.1), and is retained only for backward compatibility.

In addition, most security information and tools consider OS (external) authentication to be a security problem. I am trying to understand why this is the case. Here are some advantages I see of OS authentication:

1. Without OS Authentication applications must store passwords in a variety of applications each with their own security model and vulnerabilities.
2. Domain authentication already has to be secure because if it is not then database security just slows down access to the database, but cannot prevent it.
3. Users that only have to remember one domain password can be made to create more secure domain passwords more easily than they can be made to create even less secure database passwords as the number of different databases they must connect to increases.

Answer 1

Consider the following scenario:

1. There is a Unix user named gaius on the Oracle server with external authentication, so in Oracle there is a corresponding user called ops$gaius. When logged into a shell, I can also log straight into my Oracle schema, and my cron jobs don't need a password embedded in script either.
2. Remote OS authentication is permitted, on the assumption that the LAN is 100% secure and the clients can be trusted (same as rlogin/rsh used to be normally allowed)
3. An attacker gets his or her laptop onto the LAN by whatever means, knows that I work there, and creates a local user on their laptop called gaius and runs SQL*Plus as that user
4. Oracle sees (i.e. OSUSER in V$SESSION) is gaius and logs that remote user in as ops$gaius

That's not only laughably easy to spoof, but putting on my cynic's hat, Oracle can't make any more money selling you their fancy single sign-on product... Which by the way does fulfill all the points you raise as advantages of OS-level auth. Two passwords better than one is entirely spurious; most people will set them to be the same anyway (there's no mechanism in Oracle to prevent this).

The general principle is that it is extremely difficult to defend in software when an attacker has physical access. And never trust the client.

Answer 2

It increases single points of failure and enlarges the risk surface of your data.

An attacker who gains access to the system will, with OS Authentication, have access to the database. By requiring more secure access to the database, the potential attacker must escalate their privileges on the compromised system to gain root or oracle access, rather than any user.

This problem is a function of external access to the database. If there is no external access and the machine is fully secured then the question of permissions is moot. However, if developers have access, OS level user permissions increase the scope of potential security disasters.

Consider using multitier access to limit the scope of security breaches and give any user, application, or client the access they need without the need to create OS level accounts for every instance.

Answer 3

Gaius has already pointed out why remote operating system authentication (as opposed to vanilla operating system authentication where you are allowing local machine users to access the database without specifying a separate password) is relatively insecure.

I would expect that Oracle is moving in this direction because it wants to encourage people to use enterprise users (or the full-fledged identity management suite) rather than remote operating system authenticated users. Enterprise users have the same advantages as remote operating system authenticated users but Oracle is actually going out and hitting your Active Directory server to authenticate the user. You get the same single sign on benefits without leaving the security check up to the client machine.

Answer 4

You specifically point to ident-style authentication, but I'd also like to point out that other methods of tying database or any other logins to the OS's logins are just as bad. (be it local password files, LDAP, or whatever for the actual storage of the credentials)

If you allow remote connections to the database (or webserver, or whatever's doing the authentication), some OSes will ignore rules that might be set to make it difficult to brute force accounts (eg, blocking IPs where the failed attempts are coming from; locking users for a period after a set number of falures, etc). Normally, these rules are tied into sshd, and not the authentication system as a whole.

So, should someone be able to connect to the database / webserver / whatever remotely, they can brute force the password, as databases don't tend tend to have the same mechanisms to slow attempts, then ssh in once they find the necessary credentials.