Password Verification Security Loophole

Share Button

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:

Password Security

Padlock SecurityFor 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

We are running Oracle Enterprise Edition (11gR2) on a Linux server.

Turn off verification and create the user

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

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

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

Security PanicRunning 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.


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:

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.

Share Button


  1. 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.

  2. 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)

  3. 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

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.