For authentication, newer versions of Oracle (11g+) use a session agreement and key exchange scheme known as O5Logon. It has some of the same weaknesses of authentication as the O3Logon used in previous versions of Oracle.

An example transcript of the default auth process:
1) Client connects to Server:
2) Client sends Username to Server
3) Server generates a ServerSessionID and encrypts it with AES. The key is the PasswordHash. It sends this encrypted ServerSessionID and the PasswordSalt to the Client
4) Client tries to generate a password hash using the PasswordSalt and the provided password. It decrypts the ServerSessionID using this ClientPasswordHash
5) Client generates a ClientSessionID and encrypts it with AES. The key is the ClientPasswordHash. It combines ServerSessionID and ClientSessionID to make another key which it uses to directly encrypt the provided password. It sends this encrypted password and encrypted ClientSessionID to the Server.

A more in-depth breakdown of the steps involved can be found here.

So, although there is a lot going on, the password itself is never really sent in clear text. This scheme also prevents against replay attacks, since the session IDs are different each time. The drawback is the fact that capturing all of the transmissions can allow an attacker to brute force the password in an offline environment. This is possible because guessing the hash will allow an attacker to simply decrypt the password sent from the client by sniffing the transmissions and comparing them later.

I think it’s possible to gain the same reply protection without exposing the password like that, but it would almost certainly take more steps. This scheme was probably designed to be very fast while providing protection against the most common attack scenarios. In comparison, TLS-based authentication is an alternative to O5Logon for Oracle, and does all sorts of cert. exchanging and flippidy floppidy. It provides better protection, but at the potential expense of being overkill if you just want decently secure authentication, and I think that’s one reason it’s an option instead of the default. In general, O5Logon is fine if the user chooses a strong password. As usual, the most critical link in the security chain is the individual.

Each Thursday, Security Musings features a security-related technology or tool. Featured items do not imply a recommendation by Gemini Security Solutions. For more information about how Gemini Security Solutions can help you solve your security issues, contact us!

2 thoughts on “A Brief Look at O5Logon

  1. Malieh says:

    In the 3rd paragraph,latest sentence,

    “This is possible because guessing the hash will allow an attacker to simply decrypt the password sent from the client by sniffing the transmissions and comparing them later.”

    you mentioned the word of “decrypt” for the password “hash”!

    While decryption has been never one-way cryptography!

Comments are closed.