Oracle FAQ Your Portal to the Oracle Knowledge Grid

Home -> Community -> Mailing Lists -> Oracle-L -> Re: Passwords and authentication

Re: Passwords and authentication

From: <>
Date: Fri, 20 Jun 2003 18:53:09 -0700
Message-ID: <>

What about



SQLNET.CRYPTO_SEED = "The quick brown fox jumps over the lazy dog."

in sqlnet.ora

Passwords and authenticationRaj,

My first question will be how you would want to pass the encrypted password. sqlplus <username>/<encyptedpass>? But won't the encrypted password be known before making the connection? If so, then the user who will encrypt the password will also know how to decrypt them. What's the advantage in doing that?

Are you concerned someone sniffing the network uncovers a clear password? If so, have you considered network security with password encryption by Oracle Net?

If that is not the concern but rather you don't want the users to know the real password, here is a solution you might be interested. It's part of a elaborate application security design. Please read on if you are interested.

You would have user called SECUSER with only table APP_USERS. The table has two columns - APP_USER and APP_PASS, in encrypted manner, with Triple DES Encryption. The user also has one function - check_app_password, which accepts two parameters - the userid and the password and returns a string. The return value is YES is the password supplied is correct and NO, if it isn't. It does not shw the correct password, ever; just shows if the supplied password is correct or not. This function is defined as DEFINER rights. All users get an execute privilege on this function, nothing else on the rest of the objects of the SECUSER user.

Inside the function, the password is retrieved from the table, decrypted with the key inside the procedure and matched with the supplied one. Another function is provided to encrypt the password using teh same key. For more ecurity, the userid and password combination can encrypted, not just the password. If you want I can give you the code for the functions.

When the app user connects, the connection is done through a generic id, that, after the conenction, validates the password using the function and authenticates the user. If the password is not correct, the user is booted out.

Now comes other issues - fine grained access control and fine grained auditing. These features need to have a sepcific named database user. However, that can be easily fixed by setting up an application context and passing the app_user value to a context attribute. This attribute can now be tracked, rather than the userid.

Hope this helps.

Arup Nanda

  Is it possible to connect to database using encrypted passwords? Using sqlplus?


  Rajendra dot Jamadagni at nospamespn dot com   All Views expressed in this email are strictly personal.   QOTD: Any clod can have facts, having an opinion is an art !


Please see the official ORACLE-L FAQ:


Fat City Network Services    -- 858-538-5051
San Diego, California        -- Mailing list and web hosting services
To REMOVE yourself from this mailing list, send an E-Mail message to: [EMAIL PROTECTED] (note EXACT spelling of 'ListGuru') and in the message BODY, include a line containing: UNSUB ORACLE-L (or the name of mailing list you want to be removed from). You may also send the HELP command for other information (like subscribing). Received on Fri Jun 20 2003 - 20:53:09 CDT

Original text of this message