Pete Finnigan's Oracle Security Weblog

I saw an interesting thread on Tom Kyte's site last night. I found the post via VS Babu's Oracle feed of feeds, which is an excellent site BTW. The thread on Tom's site is called "storing passwords in the database" and is quite old in origin, the original question was posted 2 May 2000 and most recently yesterday. A long running thread but covering a good range of issues around encryption, hashing and application based password encryption / hashing and storage.

The thread starts of by showing some sample code that hashes usernames and passwords into a hash and displays them. This sort of function can be used to hash application user’s passwords and the results can be stored in a database table. The same algorithm can then be used to authenticate application users by again hashing their usernames and passwords and checking that the same value is returned. This is a common method to implement application based authentication whereby a common database user is used in the background by all users then their application user and password are authenticated by the application source code. There is also a sample function given to compare hashed passwords that could be used in an application.

Tom then explains the hash space and the issue of collisions. Tom also talks about the problem of Oracle changing the algorithm for the hash code in DBMS_UTILITY.GET_HASH_VALUE. Tom also gives some great guidance about passwords being transmitted in clear text. Also check out my posts Passwords in clear text for ALTER USER in SQL*Net and Issues with bypassing password protected roles for a discussion about password leakage on the network.

Tom also discusses the DBMS_OBFUSCATION_TOOLKIT MD5 functions and why they are better than DBMS_UTILITY.GET_HASH_VALUE. There is also an interesting section about a quite often used technique whereby an application users password is obfuscated in the background before its used to access the database. This is so the user does not know the real database password and cannot therefore use it to directly access the database via SQL*Plus or similar tool instead of the applications. Somehow this idea is flawed as access to the code or network sniffing can reveal the real password being returned to the user. See my Oracle Security Tools page for some tools to grab the Oracle SQL text from the OCI API or JDBC API.

Tom also mentions that the 10g DBMS_CRYPTO supports more algorithms and that it supports better hashing algorithms than MD5 such as SHA-1. If you do not have 10g then a poster also provides a simple Java database procedure to implement SHA-! in versions before 10g - Java is needed of course.

A good thread, worth reading for the ideas used in some applications to authenticate users. A much better solution than the common database user and hand built authentication is to use Oracle features such as connection pooling and proxy users or single sign on in ASO or LDAP.