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;
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.
spare4 column's value has three parts ("
H:", and "
T:") separated by semicolons.
S:" part length is 60 characters or 30 bytes:
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 http://marcel.vandewaters.nl/oracle/security/password-hashesfor more detail.)
The same is true of Oracle Database 12c: the simple test below proves that.
S value from above (
Password is "
epsilon", so let's calculate SHA1 hash from
'epsilon' + 0x6271691FC55C1F56554A:
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
(USERNAME, HAS_DIGEST_VERIFIERS, DIGEST_TYPE) as
select u.name, 'YES', 'MD5' from user$ u where instr(spare4, 'H:')>0
select u.name, '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:
m = hashlib.md5()
This makes it possible to attack built-in user passwords using pre calculated hashes for dictionary words prefixed with constants like '
H value seems to be used for digest authentication in XDB.
The T part
This applies to 126.96.36.199 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 188.8.131.52 distribution too):
SQLNET.ALLOWED_LOGON_VERSION_SERVER = 12a
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
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
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
E3243B98974159CC24FD2C9A8B30BA62E0E83B6CA2FC7C55177C3A7F82602E3BDD17CEB9B9091CF9DAD672B8BE961A9EAC4D344BDBA878EDC5DCB5899F689EBD (first 128 chars or 64 bytes)
8DD1BE3F67BFF9813A464382381AB36B (last 32 chars or 16 bytes -
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
salt = AUTH_VFR_DATA + b'AUTH_PBKDF2_SPEEDY_KEY'
key = pbkdf2.PBKDF2("epsilon", salt, 4096, hashlib.sha512) # Password
key_64bytes = key.read(64) # 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
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
12Cverifier 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
When the MD5 hash is there it weakens security since it is easier to brute force than the PBKDF2-based SHA512 alone.