Oracle Logon Protocol (O3LOGON) in 10g

Question

I am studying the Oracle mechanism for authentication in a 10g database. Although less documented than its 9i mapper, I still managed to find many of its details on various websites and blogs. However, one part remains a mystery. Before mentioning what is missing, let me explain what is known about the protocol in pseudo-code:

// CLIENT SIDE PSEUDO CODE user = "SCOTT" password = "TIGER" password_hash = oracle_password_hash(user, password) // 1. Client provides user name to server send(user) // 2. Server responds with its encrypted AUTH_SESSKEY, // a randomly generated number associated with the current session encrypted_server_AUTH_SESSKEY = receive_AUTH_SESSKEY() // 32 bytes decrypted_server_AUTH_SESSKEY = aes_decrypt( encrypted_input => encrypted_server_AUTH_SESSKEY, decryption_key => password_hash ) // 3. Client generates its own AUTH_SESSKEY for this session unencrypted_client_AUTH_SESSKEY = generate_random_AUTH_SESSKEY() // 32 bytes encrypted_client_AUTH_SESSKEY = aes_encrypt( unencrypted_input => unencrypted_client_AUTH_SESSKEY, encryption_key => password_hash ) // 4. Client combines the two AUTH_SESSKEYs using a known Oracle-specific algorithm combined_AUTH_SESSKEYs = oracle_combine(decrypted_server_AUTH_SESSKEY, unencrypted_client_AUTH_SESSKEY) // 5. Client builds AUTH_PASSWORD unencrypted_AUTH_PASSWORD = byte[32] unencrypted_AUTH_PASSWORD[0 .. 16] = ??? // THIS IS THE PROBLEM unencrypted_AUTH_PASSWORD[16 .. 16 + len(password)] = password unencrypted_AUTH_PASSWORD[16 + len(password) .. ] = PKCS#7 padding // 6. Client encrypts the AUTH_PASSWORD data using the combined AUTH_SESSKEYs as the encryption key encrypted_AUTH_PASSWORD = aes_encrypt( unencrypted_input => unencrypted_AUTH_PASSWORD, encryption_key => combined_AUTH_SESSKEYs ) // 7. Client transmits its encrypted AUTH_SESSKEY and AUTH_PASSWORD to server for verification send(encrypted_client_AUTH_SESSKEY, encrypted_AUTH_PASSWORD) 

What did the Oracle client put AUTH_PASSWORD in the bottom 16 bytes in step 5?

Almost all of the documentation I found only cares about getting the plain text password contained inside, paying little attention to these first bytes. I tried to look at the JDBC driver, but it seems that even version 10g avoids this authentication scheme, referring to the server returning to an older scheme (which is much better understood). The excellent C program demonstrates AUTH_PASSWORD decryption.

Can someone point me in the right direction?

Answer 1

I determined that 16 bytes immediately before the plaintext password are randomly generated (for the curious, take a look at the ztvo5pe function exported by the oran10.dll library - you will see two consecutive ztcen calls, the first call fills it).

I originally posted the question because I wrote a small program to connect to an Oracle database without using the Oracle JDBC driver. I found that the database rejected my 32-byte AUTH_PASSWORD. I assumed that it was rejected because I set the wrong value in these first 16 bytes. I was wrong. It does not seem to affect whether the user is authenticated.

Rather, it turns out that the database rejected my AUTH_PASSWORD due to trailing bytes that appear immediately after the plaintext password. I naively filled a buffer with zeros. It must be supplemented in accordance with PKCS specification No. 7.

Answer 2

If the password length is <16, the first 16 bytes are random data, then the password, filling data - char (16 - strlen (password)). Oracle server can accept my AUTH_PASSWORD. If the password length is> = 16, I do not know how to do this. I filled the first 16 bytes with random data, but the server rejected my data. I want to know: are you sure that these add-ons comply with PKCS # 7 specification.