Leighton Nelson asked an interesting Oracle security question via Twitter yesterday regarding Oracle’s built-in password verification functions and whether or not it can be bypassed by changing the way you create a user:
Does updating password via alter user identified by values "<encrypted value>" bypass profile settings in 11.2.03? I say no but DBA says yes
— Leighton L. Nelson (@leight0nn) July 15, 2013
Password Security
For some background, Oracle profiles are applied to every user in your database. By default, there’s a profile called DEFAULT (imagine that) with some general security settings for password expiration time, lock time if you enter the wrong password too many times, etc. One of the possible settings is a password verification function. The PASSWORD_VERIFY_FUNCTION profile setting can point to a custom function that tests a password for whatever security rules you want: ensure the password != username, that is is not in a dictionary of simple words, or that it is a certain length. With REGEX functions you can make it as complex as you need it to be to ensure passwords are always thoroughly complex. Oracle includes one by default called VERIFY_FUNCTION_11G (in 11g of course) that you can create by running $ORACLE_HOME/rdbms/admin/utlpwdmg.sql as the SYS user.
The primary purpose for these types of functions are, of course, so you can ensure all users in your database comply with standards–whether company, government, or certification board. It is highly important that these types of security features be foolproof, as an infraction (especially one that goes unknown) could be highly detrimental to your job or business. So I decided to test Leighton’s scenario.
Setting up the test
To test whether you can workaround the password verification function security setting with a ‘USING VALUES’ password on a user, I first need to verify that the password verification function is turned off, create a user with a simple password, get the DDL for the user, and then drop the user.
Verify the Version
SQL> select * from v$version; BANNER ---------------------------------------------------------------------------- Oracle Database 11g Enterprise Edition Release 11.2.0.3.0 - 64bit Production PL/SQL Release 11.2.0.3.0 - Production CORE 11.2.0.3.0 Production TNS for Linux: Version 11.2.0.3.0 - Production NLSRTL Version 11.2.0.3.0 - Production
We are running Oracle Enterprise Edition 11.2.0.3 (11gR2) on a Linux server.
Turn off verification and create the user
SQL> select limit from dba_profiles where resource_name = 'PASSWORD_VERIFY_FUNCTION'; LIMIT ------------------- VERIFY_FUNCTION_11G SQL> alter profile default limit password_verify_function null; Profile altered. SQL> create user steve identified by abc123; User created.
First the profile was set to turn off verification. The user ‘steve’ was created with a simple password of ‘abc123’ which is too short for Oracle’s default verify function (it requires 8 characters minimum).
Grab the DDL and drop the user
SQL> select dbms_metadata.get_ddl('USER', 'STEVE') from dual; DBMS_METADATA.GET_DDL('USER','STEVE') ----------------------------------------------------------------------------------------------------------------------------- CREATE USER "STEVE" IDENTIFIED BY VALUES 'S:B7064D9684925F17F432168693807C8751619C489B41151BEAD55E3C6ED3;B10FF62B943CB07D' SQL> drop user steve; User dropped.
The DDL for user ‘steve’ contains an encrypted password with the ‘BY VALUES’ clause. If this DDL is run, it will create the user ‘steve’ with the same password they had previously. This should not be able to bypass security settings, however…
Doing the deed
Turn on verification and test with a simple password
SQL> alter profile default limit password_verify_function verify_function_11g; Profile altered. SQL> create user steve identified by abc123; create user steve identified by abc123 * ERROR at line 1: ORA-28003: password verification for the specified password failed ORA-20001: Password length less than 8
This snippet confirms that the verification function is turned on and disallows passwords with less than eight characters. The ‘abc123’ password does not work.
Bypass the verification function
SQL> CREATE USER "STEVE" IDENTIFIED BY VALUES 'S:B7064D9684925F17F432168693807C8751619C489B41151BEAD55E3C6ED3;B10FF62B943CB07D'; User created. SQL> grant create session to steve; Grant succeeded. SQL> connect steve/abc123 Connected.
Running the user creation with the ‘IDENTIFIED BY VALUES’ clause does in fact bypass the verification function and allow a simple (and not at all secure) password of ‘abc123’. I was able to create the user, grant create session, and connect. Ouch. While Pete Finnigan has created a Password Audit tool to check for default passwords, I don’t believe there’s any method to check existing passwords for complexity.
Update
A response on Twitter mentioned the fact that I was using the SYS account for this test. However, anyone with the ALTER USER privilege (not audited like SYS) can use this workaround:
SQL> grant dba to steve; Grant succeeded. SQL> connect steve/abc123 Connected. SQL> alter user steve identified by abc123; alter user steve identified by abc123 * ERROR at line 1: ORA-28003: password verification for the specified password failed ORA-20001: Password length less than 8 SQL> alter user steve identified by VALUES 'S:B7064D9684925F17F432168693807C8751619C489B41151BEAD55E3C6ED3;B10FF62B943CB07D'; User altered.
Update 2
Laurent Schneider mentioned in the comments that granting DBA is also license to get around the rules. However, granting CREATE USER or ALTER USER also permits this loophole. While DBA and SYSDBA are arguably roles that permit tampering with no way to stop it, CREATE USER and ALTER USER grantees should absolutely be forced to play by the rules.
SQL> revoke dba from steve; revoke dba from steve * ERROR at line 1: ORA-01951: ROLE 'DBA' not granted to 'STEVE' SQL> grant alter user to steve; Grant succeeded. SQL> connect steve/abc123 Connected. SQL> alter user steve identified by abc123; alter user steve identified by abc123 * ERROR at line 1: ORA-28003: password verification for the specified password failed ORA-20001: Password length less than 8 SQL> alter user steve identified by VALUES 'S:B7064D9684925F17F432168693807C8751619C489B41151BEAD55E3C6ED3;B10FF62B943CB07D'; User altered. SQL> connect steve/abc123 Connected.
but identified by values is not even a supported syntax, right?
http://docs.oracle.com/cd/E16655_01/server.121/e17209/statements_4003.htm#i2058207
if you grant dba to steve then its your fault the security is compromise, imho
Laurent, granting CREATE USER or ALTER USER also does the same thing. While I’d agree that granting DBA is an invitation to compromise security, CREATE USER privileges should not give you the right to circumvent the user creation rules, but to create a user while following them.
I’ll update the blog post to reflect this.
Thanks Steve for the followup.
ALTER USER / CREATE USER are still powerfull privileges.
If you have ALTER USER, you can also change the user default profile (and potentially bypass the default password function)
Hi Steve,
I added some of my own analysis to your idea in a post on my site – http://www.petefinnigan.com/weblog/archives/00001369.htm
cheers
Pete
Hi Steve,
Oracle’s password value is a hash value (i.e. one way), not an encrypted value that can be decrypted by oracle. so there’s no way that the password verifier function will ever know what the plaintext password is if you provide it with the password hashed value using the “by values” clause. Oracle would need to use a technique as provided by Pete which is to apply its own password hashing algorithm to a bunch of candidate passwords and then see if it matches the stored hash.
Best regards,
Andre van Winssen
or possibly disable “identified by values” for ALTER USER and create a special “IDENTIFIED BY VALUES” privilege