1. Concatenate the username and the password to produce a plaintext string;

2. Convert the plaintext string to uppercase characters;

3. Convert the plaintext string to multi-byte storage format; ASCII characters have the high byte set to 0x00;

4. Encrypt the plaintext string (padded with 0s if necessary to the next even block length) using the DES algorithm in cipher block chaining (CBC) mode with a fixed key value of 0x0123456789ABCDEF;

5. Encrypt the plaintext string again with DES-CBC, but using the last block of the output of the previous step (ignoring parity bits) as the encryption key. The last block of the output is converted into a printable string to produce the password hash value.

Oracle Global Product Security has investigated the recent publication by Joshua Wright of the SANS Institute, and Carlos Cid of the University of London’s Royal Holloway College, entitled “An Assessment of the Oracle Password Hashing Algorithm.” This paper presents an analysis of the Oracle Database password hashing algorithm. It describes potential attacks against this algorithm when an attacker has access to password hash information.

Oracle considers adherence to industry standard security practices the best way for customers to protect their database systems. In particular, issues noted in the paper can be addressed through limiting access to password hash information, and by enforcing good enterprise password policies. Moreover, Oracle customers have authentication options available which avoid the issues described in this paper.[...]

What happens if this attack is launched in a perfect world? In the perfect world all systems - database and host operating system - are fully patched. No known exploits work. All users have only got the privileges they really need. Unauthorized hash retrieval is not possible. Default username/password combinations do not exist anymore since passwords are changed or accounts are disabled. Therefore unauthorized access is not possible. In a prefect world, if a database administrator selects a view or table containing the hashes1, it will be recorded in the audit trail and disciplinary action can be taken. In such an environment, the conclusion is that an attacker will not be able to obtain the encrypted passwords. No reference material means no cracking therefore no risk. End of story? No, not at all.

The purpose of Authentication Key Fold-in is to defeat a posible third party attack (historically called the man-in-the-middle attack) on the Diffie-Hellman key negotiation. It strengthens the session key significantly by combining a shared secret, known only to the client and the server, with the original session key negotiated by Diffie-Hellman.

The client and the server begin communicating using the session key generated by Diffie-Hellman. When the client authenticates to the server, they establish a shared secret that is only known to both parties. Oracle Advanced Security combines the shared secret and the Diffie-Hellman session key to generate a stronger session key designed to defeat a man-in-the-middle attack.