Trustwave SpiderLabs Exposes Unique Cybersecurity Threats in the Public Sector. Learn More

Trustwave SpiderLabs Exposes Unique Cybersecurity Threats in the Public Sector. Learn More

Managed Detection & Response

Eliminate active threats with 24/7 threat detection, investigation, and response.

Co-Managed SOC (SIEM)

Maximize your SIEM investment, stop alert fatigue, and enhance your team with hybrid security operations support.

Advisory & Diagnostics

Advance your cybersecurity program and get expert guidance where you need it most.

Penetration Testing

Test your physical locations and IT infrastructure to shore up weaknesses before exploitation.

Database Security

Prevent unauthorized access and exceed compliance requirements.

Email Security

Stop email threats others miss and secure your organization against the #1 ransomware attack vector.

Digital Forensics & Incident Response

Prepare for the inevitable with 24/7 global breach response in-region and available on-site.

Firewall & Technology Management

Mitigate risk of a cyberattack with 24/7 incident and health monitoring and the latest threat intelligence.

Offensive Security
Solutions to maximize your security ROI
Microsoft Exchange Server Attacks
Stay protected against emerging threats
Rapidly Secure New Environments
Security for rapid response situations
Securing the Cloud
Safely navigate and stay protected
Securing the IoT Landscape
Test, monitor and secure network objects
Why Trustwave
About Us
Awards and Accolades
Trustwave SpiderLabs Team
Trustwave Fusion Security Operations Platform
Trustwave Security Colony
Technology Alliance Partners
Key alliances who align and support our ecosystem of security offerings
Trustwave PartnerOne Program
Join forces with Trustwave to protect against the most advance cybersecurity threats
SpiderLabs Blog

Changes in Oracle Database 12c password hashes

Oracle has made improvements to user password hashes within Oracle Database 12c. By using a PBKDF2-based SHA512 hashing algorithm, instead of simple SHA1 hash, password hashing is more secure. With this post, I'll explain some of the changes and their security implications.

With Oracle Database 11g, the spare4 column from the sys.user$ table stores user password hashes.

This is an example of the sys.user$.spare4 entry for user 'demo' with password 'epsilon' (pluggable database):



SQL> create user demo identified by epsilon;

User created.

SQL> select spare4 from sys.user$ where name = 'DEMO';


sys.user$.password value for the same user:

SQL> select password from sys.user$ where name = 'DEMO';


This will omit the password value discussion: it is calculated using the same algorithm (uppercase and concatenate username and password then do 3DES hashing) as in previous Oracle Database versions.

The spare4 column's value has three parts ("S:", "H:", and "T:") separated by semicolons.

The "S:" part length is 60 characters or 30 bytes:


The "H:" part length is 32 characters or 16 bytes:


Finally, the "T:" part length is 160 characters or 80 bytes:


So what do they mean exactly?

The S part

In Oracle Database 11g there is "S:" part and it is created as follows:

password hash (20 bytes) = sha1(password + salt (10 bytes))

(Visit more detail.)

The same is true of Oracle Database 12c: the simple test below proves that.

For the S value from above (8F2D65FB5547B71C8DA3760F10960428CD307B1C6271691FC55C1F56554A):

hash is 8F2D65FB5547B71C8DA3760F10960428CD307B1C
salt is 6271691FC55C1F56554A

Password is "epsilon", so let's calculate SHA1 hash from 'epsilon' + 0x6271691FC55C1F56554A:

import hashlib
sha1 = hashlib.sha1()

That calculation produces:


This is identical to the 11g algorithm.

The H part

When looking through SQL files under $ORACLE_HOME/rdbms/admin one can spot this:

create or replace view DBA_DIGEST_VERIFIERS
select, 'YES', 'MD5' from user$ u where instr(spare4, 'H:')>0
select, 'NO', NULL from user$ u where not(instr(spare4, 'H:')>0) or spare4 is null

So it appears to be a MD5 hash.

Note that there is SQL code under $ORACLE_HOME/rdbms/admin that modifies the spare4 column's value to remove the H: on downgrade.

This is how spare4.H is calculated: the username is uppercased, then the MD5 hash is calculated from it, and 'XDB' and password are separated by colons:

import hashlib
m = hashlib.md5()

This makes it possible to attack built-in user passwords using pre calculated hashes for dictionary words prefixed with constants like 'SYSTEM:XDB:'.

The H value seems to be used for digest authentication in XDB.

The T part

This applies to only. For previous 12c versions the T part is not available.

Let's enable 12c passwords hashes only by updating the sqlnet.ora file (assuming the client is from distribution too):

# sqlnet.ora

Then re-create the demo user (reconnect the client first):

drop user demo;
create user demo identified by epsilon;
select spare4 from sys.user$ where name = 'DEMO';


Note that the spare4 value no longer has the S: part, only the H: and T: components are there.

In Oracle Database 12c documentation we can find this:

About the 12C Verifier
... is based on a de-optimized algorithm involving PBKDF2 and SHA512...

So the password should be processed via PBKDF2 followed by SHA512 to produce T.

During authentication the server sends so called AUTH_VFR_DATA (which matches the last 16 bytes of the spare4.T value) to the client:

-- Server to client packet snippet
39 39 39 00 00 00 00 0D-00 00 00 0D 41 55 54 48 999.........AUTH
5F 56 46 52 5F 44 41 54-41 20 00 00 00 20 38 44 _VFR_DATA.....8D
44 31 42 45 33 46 36 37-42 46 46 39 38 31 33 41 D1BE3F67BFF9813A
34 36 34 33 38 32 33 38-31 41 42 33 36 42 15 48 464382381AB36B.H

So we can divide the T value into two parts (first 64 bytes and the AUTH_VFR_DATA):

E3243B98974159CC24FD2C9A8B30BA62E0E83B6CA2FC7C55177C3A7F82602E3BDD17CEB9B9091CF9DAD672B8BE961A9EAC4D344BDBA878EDC5DCB5899F689EBD (first 128 chars or 64 bytes)
8DD1BE3F67BFF9813A464382381AB36B (last 32 chars or 16 bytes - AUTH_VFR_DATA)

Let's assume that the AUTH_VFR_DATA is randomly generated when a password is set/reset. Thus Python code to produce the first 64 bytes of T is (requires PBKDF2 Python module):

import pbkdf2, hashlib
AUTH_VFR_DATA = b'\x8d\xd1\xbe\x3f\x67\xbf\xf9\x81\x3a\x46\x43\x82\x38\x1a\xb3\x6b' # This is received from the server once the latest protocol is negotiated
key = pbkdf2.PBKDF2("epsilon", salt, 4096, hashlib.sha512) # Password
key_64bytes = # This 64-byte derived key is encrypted by the client and sent to the server as AUTH_PBKDF2_SPEEDY_KEY

t = hashlib.sha512() # This happens on the server after they key is decrypted from the AUTH_PBKDF2_SPEEDY_KEY value
t.hexdigest().upper() # First 64 bytes of spare4.T: value if password is correct

This produces:


Summing up

Oracle has added MD5 hash and PBKDF2-based SHA512 hash in 12c. A quote from Oracle documentation:

The cryptographic hash function used for generating the 12C verifier is based on a de-optimized algorithm involving PBKDF2 and SHA-512. The PBKDF2 algorithm is used to introduce computational asymmetry in the challenge facing an intruder seeking to recover the original password when in possession of the 12C verifier.

When the MD5 hash is there it weakens security since it is easier to brute force than the PBKDF2-based SHA512 alone.

Latest SpiderLabs Blogs

Important Security Defenses to Help Your CISO Sleep at Night

This is Part 13 in my ongoing project to cover 30 cybersecurity topics in 30 weekly blog posts. The full series can be found here.

Read More

2024 Public Sector Threat Landscape: Trustwave Threat Intelligence Briefing and Mitigation Strategies

Trustwave SpiderLabs’ 2024 Public Sector Threat Landscape: Trustwave Threat Intelligence Briefing and Mitigation Strategies report details the security issues facing public sector security teams as...

Read More

How to Create the Asset Inventory You Probably Don't Have

This is Part 12 in my ongoing project to cover 30 cybersecurity topics in 30 weekly blog posts. The full series can be found here.

Read More