(/en-

us/)


BLOGS & STORIES

SpiderLabs Blog
Attracting more than a half-million annual readers, this is the
security community's go-to destination for technical breakdowns
of the latest threats, critical vulnerability disclosures and cutting-
edge research.

Changes in Oracle Database 12c

password hashes
access_time June 01, 2015 person_outline Martin Rakhmanov

share
(https://twitter.com/share?
(https://www.linkedin.com/shareArticle?
(https://www.facebook.com/sharer/sharer.php
Oracle has made improvements to user password hashes
url=https://www.trustwave.com/en-
within Oraclemini=true&url=https://www.trustwave.com/en-
u=https://www.trustwave.com/en-
Database 12c. By using a PBKDF2-based
SHA512 hashing algorithm, instead of simple SHA1 hash,
us/resources/blogs/spiderlabs-
us/resources/blogs/spiderlabs-
us/resources/blogs/spiderlabs-
password hashing is more secure. With this post, I'll explain
blog/changes-
blog/changes-
blog/changes-
some of the changes and their security implications.
in- in- in-
With Oracle Database 11g, the spare4  column from the
oracle- oracle- oracle-
sys.user$  table stores user password hashes.
database-
database-
database-
This is an example of the sys.user$.spare4  entry for user
12c- 12c- 12c-
' demo ' with password ' epsilon ' (pluggable database):
password-
password-
password-
S:8F2D65FB5547B71C8DA3760F10960428CD307B1C6271691FC55C1
hashes/&text=Changes
hashes/&title=Changes
hashes/)
F56554A;H:DC9894A01797D91D92ECA1DA66242209;T:23D1F8CAC9
in in
001F69630ED2DD8DF67DD3BE5C470B5EA97B622F757FE102D8BF14B
We use cookies to provide you a relevant user experience, analyze our traffic, and provide social
Oracle Oracle GOT IT
media features. Privacy Policy (https://www.trustwave.com/en-us/legal-documents/privacy-policy/)
 EDC94A3CC046D10858D885DB656DC0CBF899A79CD8C76B788744844
Database
Database
CADE54EEEB4FDEC478FB7C7CBFBBAC57BA3EF22C
12c
12c

Step-by-step:
password
password

hashes+-
hashes)
SQL> create user demo identified by epsilon;

+Trustwave)
User created.

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

SPARE4
-------------------------------------------------------
-------------------------

S:8F2D65FB5547B71C8DA3760F10960428CD307B1C6271691FC55C1
F56554A;H:DC9894A01797D91D92ECA1DA66242209;T:23D1F8CAC9
001F69630ED2DD8DF67DD3BE5C470B5EA97B622F757FE102D8BF14B
EDC94A3CC046D10858D885DB656DC0CBF899A79CD8C76B788744844
CADE54EEEB4FDEC478FB7C7CBFBBAC57BA3EF22C

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

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

'DEMO';

PASSWORD
-------------------------------------------------------

-------------------------
2B7983437FE9FEB6

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:

8F2D65FB5547B71C8DA3760F10960428CD307B1C6271691FC55C1F5

We use cookies to provide you a6554A

relevant user experience, analyze our traffic, and provide social
media features. Privacy Policy (https://www.trustwave.com/en-us/legal-documents/privacy-policy/)
 The " H: " part length is 32 characters or 16 bytes:

DC9894A01797D91D92ECA1DA66242209

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

23D1F8CAC9001F69630ED2DD8DF67DD3BE5C470B5EA97B622F757FE
102D8BF14BEDC94A3CC046D10858D885DB656DC0CBF899A79CD8C76
B788744844CADE54EEEB4FDEC478FB7C7CBFBBAC57BA3EF22C

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-
hashes
(http://marcel.vandewaters.nl/oracle/security/password-
hashes)for more detail.)

The same is true of Oracle Database 12c: the simple test

below proves that.

For the S  value from above

( 8F2D65FB5547B71C8DA3760F10960428CD307B1C6271691FC55C1F5655
4A ):

hash is 8F2D65FB5547B71C8DA3760F10960428CD307B1C
salt is 6271691FC55C1F56554A

Password is " epsilon ", so let's calculate SHA1 hash from

'epsilon' + 0x6271691FC55C1F56554A :

import hashlib
sha1 = hashlib.sha1()

sha1.update("epsilon")
sha1.update('\x62\x71\x69\x1f\xc5\x5c\x1f\x56\x55\x4a'
)
We use cookies to provide you a relevant user experience, analyze our traffic, and provide social
sha1.hexdigest().upper()
media features. Privacy Policy (https://www.trustwave.com/en-us/legal-documents/privacy-policy/)
 That calculation produces:

' 8F2D65FB5547B71C8DA3760F10960428CD307B1C '

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
union
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:

import hashlib
m = hashlib.md5()
m.update('DEMO:XDB:epsilon')
m.hexdigest().upper()

'DC9894A01797D91D92ECA1DA66242209'

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.
We use cookies to provide you a relevant user experience, analyze our traffic, and provide social
The
media features. Privacy Policy T part
(https://www.trustwave.com/en-us/legal-documents/privacy-policy/)
 This applies to 12.1.0.2 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 12.1.0.2
distribution too):

# sqlnet.ora
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';

H:DC9894A01797D91D92ECA1DA66242209;T:E3243B98974159CC24
FD2C9A8B30BA62E0E83B6CA2FC7C55177C3A7F82602E3BDD17CEB9B

9091CF9DAD672B8BE961A9EAC4D344BDBA878EDC5DCB5899F689EBD
8DD1BE3F67BFF9813A464382381AB36B

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:

format_quote About the 12C Verifier

... is based on a de-optimized

format_quote 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:
We use cookies to provide you a relevant user experience, analyze our traffic, and provide social
media features. Privacy Policy (https://www.trustwave.com/en-us/legal-documents/privacy-policy/)
 -- 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 ):

E3243B98974159CC24FD2C9A8B30BA62E0E83B6CA2FC7C55177C3A7
F82602E3BDD17CEB9B9091CF9DAD672B8BE961A9EAC4D344BDBA878

EDC5DCB5899F689EBD  (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
(https://www.dlitz.net/software/python-pbkdf2/)):

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.update(key_64bytes)

We use cookies to provide you a relevant user experience, analyze our traffic, and provide social
media features. Privacy Policy (https://www.trustwave.com/en-us/legal-documents/privacy-policy/)
 t.update(AUTH_VFR_DATA)
t.hexdigest().upper() # First 64 bytes of spare4.T:
value if password is correct

This produces:

E3243B98974159CC24FD2C9A8B30BA62E0E83B6CA2FC7C55177C3A7
F82602E3BDD17CEB9B9091CF9DAD672B8BE961A9EAC4D344BDBA878
EDC5DCB5899F689EBD

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

format_quote 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.

Related SpiderLabs Blogs

We use cookies to provide you a relevant user experience, analyze our traffic, and provide social
media features. Privacy Policy (https://www.trustwave.com/en-us/legal-documents/privacy-policy/)
 (/en- (/en-
us/resources/blogs/spiderlabs- us/resources/blogs/spiderlabs-
blog/playdate-with-bots- blog/unc-path-injection-with-
microsoft-sql-honeypots/) microsoft-access/)

Playdate with Bots: UNC Path Injection

Microsoft SQL with Microsoft Access
Honeypots (/en- (/en-
us/resources/blogs/spide us/resources/blogs/sp
blog/playdate-with- blog/unc-path-
bots-microsoft-sql- injection-with-
SPIDERLABS BLOG SPIDERLABS BLOG

Sign up to receive the

latest security news an
trends from Trustwave
Stay Informed

Business Email SUBSCRI

English
   
(https://www.linkedin.com/company/trustwave)
(https://twitter.com/Trustwave)
(https://www.facebook.com/Trustwave/)
(https://www.youtube.com/channel/UC2CCq
Fv83NOdjhqA)

We use cookies to provide you a relevant user experience, analyze our traffic, and provide social
media features. Privacy Policy (https://www.trustwave.com/en-us/legal-documents/privacy-policy/)
Leadership Team (/en-us/company/about-us/leadership/)
 Our History (/en-us/company/about-us/our-history/)

News Releases (/en-us/company/newsroom/news/)

Media Coverage (/en-us/company/newsroom/media/)

Careers (https://jobs.jobvite.com/trustwave)

Global Locations (/en-us/company/global-locations/)

Awards & Accolades (/en-us/company/about-us/accolades/)

Trials & Evaluations (/en-us/resources/security-resources/special-offers/)

Contact (/en-us/company/contact/)

Support (/en-us/company/support/)

Security Advisories (/en-us/resources/security-resources/security-

advisories/)

Software Updates (/en-us/resources/security-resources/software-updates/)

Legal (/en-us/legal-documents/)
Terms of Use (/en-us/legal-documents/terms-of-use/)
Privacy Policy (/en-us/legal-documents/privacy-policy/)
Copyright © 2022 Trustwave Holdings, Inc. All rights reserved.

We use cookies to provide you a relevant user experience, analyze our traffic, and provide social
media features. Privacy Policy (https://www.trustwave.com/en-us/legal-documents/privacy-policy/)