Oracle Database Password Security

This is my presentation to the UKOUG last December on Oracle Database Password Security.

Slide 1 - Oracle Database Password Security

An Appreciation

Slide 2 - Legal notice

Data Security in ERP and Other Large Business Systems

Published by
PeteFinnigan.com Limited
Tower Court
3 Oakdale Road
York
England, YO30 4XL

Copyright © 2025 by PeteFinnigan.com Limited

No part of this publication may be stored in a retrieval system, reproduced or transmitted in any form by any means, electronic, mechanical, photocopying, scanning, recording, or otherwise except as permitted by local statutory law, without the prior written permission of the publisher. In particular this material may not be used to provide training of any type or method. This material may not be translated into any other language or used in any translated form to provide training. Requests for permission should be addressed to the above registered address of PeteFinnigan.com Limited in writing.

Limit of Liability / Disclaimer of warranty. This information contained in this course and this material is distributed on an “as-is” basis without warranty. Whilst every precaution has been taken in the preparation of this material, neither the author nor the publisher shall have any liability to any person or entity with respect to any loss or damage caused or alleged to be caused directly or indirectly by the instructions or guidance contained within this course.

TradeMarks. Many of the designations used by manufacturers and resellers to distinguish their products are claimed as trademarks. Linux is a trademark of Linus Torvalds, Oracle is a trademark of Oracle Corporation. All other trademarks are the property of their respective owners. All other product names or services identified throughout the course material are used in an editorial fashion only and for the benefit of such companies with no intention of infringement of the trademark. No such use, or the use of any trade name, is intended to convey endorsement or other affiliation with this course.

Slide 3 - Background

Pete Finnigan – Background, Who Am I?

• Oracle Security specialist and researcher
• CEO and founder of PeteFinnigan.com Limited in February 2003
• Writer of the longest running Oracle security blog
• Author of the Oracle Security step-by-step guide and “Oracle Expert Practices”, “Oracle Incident Response and Forensics” books
• Oracle ACE for security
• Member of the OakTable, SYM 42
• Speaker at various conferences UKOUG, PSOUG, BlackHat, more..
• Published many times, see http://www.petefinnigan.com for links

Slide 4 - Agenda

• Define the problem
• The password algorithms used
• Cracking passwords
• Security of passwords
• Password design
• Profile design
• Password safes

Slide 5 - The Problem Space – High Level

• Attacking a database needs either:
• A direct database connection (We are focusing on this one!)
• OR Exploiting an application via SQL Injection or similar
• For a direct database connection we need:
• A direct “pipe” to the database – Open or controlled routing
• Network details – IP/host, port, SID/Service Name
• A username and password
• Often: we can locate almost all of the above except the password – (tnsnames, guess usernames…..)
• BUT; often (in real sites/systems) we can also guess or find passwords

Slide 6 - The Password Algorithms in The Database

• Starting in Oracle 6 there is one core password algorithm (DES)
• Starting in 11gR1 there are 2 core algorithms (DES, SHA1)
• Starting in 12.1.0.1 there are 3 core database algorithms (DES, SHA1, HTTP Digest)
• Starting in 12.1.0.2 there are 4 core password algorithms (DES, SHA1, SHA512, HTTP Digest)
• Along the way we have also had others such as ftp via XDB
• Unless you control it all algorithms exist – more shortly on this

12.1.0.2 Example – root container – sys.user$.password and sys.user$.spare4

Slide 7 - DES

• Used from Oracle 6 through Oracle 10gR2
• Actually still enabled in 11gR1 to 12.1.0.2
• Designed by Bob Baldwin – designer of NT and VMS algorithms -https://groups.google.com/forum/#!msg/comp.databases.oracle/F0uSWBy9e_Q/7bZ_l3pVroMJ - posted to usenet in 1993
• Note that the details posted are not 100% correct
• Algorithm:
• Concatenate user|password => Unicode the string => encrypt with DES using key 0x0123456789abcdef => encrypt first block => xor next block with result => take the last IV as a new KEY and repeat
• The password hash generated is then not reversible

Strengths / weaknesses – No real attack except brute force but key is too short now

Slide 8 - SHA1

• Used in 11gR1 through 11.2.0.4
• Actually still available in 12.1.0.2
• Added case sensitive passwords to the database for first time
• As a result longer key space by default
• Password only is hashed, not username and password (in DES the username is the salt)
• Salt is generated by the database on password create/change
• Salt is passed by SQL*Net to the client
• Salt is stored in SYS.USER$.SPARE4
• Salt is to prevent same hash generated for same password
• Fast algorithm – not good for avoiding cracking..
• SHA1 is broken - https://www.schneier.com/blog/archives/2005/02/sha1_broken.html

Slide 9 - SHA2

• Only added since 12.1.0.2 – SHA2 also added to DBMS_CRYPTO
• Hinted at in 12.1.0.1 – see comments in code in .bsq file for user$ table creation for instance
• Password hash stored as T: in SYS.USER$.SPARE4 column
• Combination of SHA2 – (SHA512) and PBKDF2 algorithms
• PBKDF2 is done in the client
• SHA2 is completed in the server
• As with SHA1 the password hash and salt are stored in SYS.USER$.SPARE4
• Strengths / Weaknesses
• Much slower to crack due to PBKDF2 part so much better than SHA1 or DES for slowing cracking
• Documented as demo already on-line back in June; known longer

Slide 10 - HTTP Digest

• Added in 12.1.0.1 to all database accounts
• Strange addition; SHA2 added as much stronger algorithm but HTTP Digest added just before
• MD5 is of course a predecessor to SHA and SHA1 and must faster to execute than SHA2
• Same hash always generated for same password
• Can crack the password in PL/SQL:

Slide 11 - Disable Weaker Algorithms

Disable Weaker Algorithms

Slide 12 - Cracking Passwords

• Why do we need to crack passwords
• We need to test the strength of our passwords but unless they are weak we cannot fully do this
• A password cracker will take too long to test a 12 or more character password
• If we have 15 character passwords we cannot prove this without access to government level hardware and budget
• We must assume others can crack our passwords so we must make some efforts to test our own
• Cracking types and more
• Connect brute force
• Default passwords
• Dictionary attacks
• Brute force
• Permutes
• Top 500, 1,000, 10,000 passwords
• Dictionary languages – Switzerland!
• A simple PL/SQL based cracker can give a good overview of current password security

Demo PL/SQL based cracker on 12c

Slide 13 - Cracking More…

• C based crackers – run faster than PL/SQL so can test more passwords
• Orabf – 0rm
• Woraauthbf – Laszlo Toth
• Checkpwd – Alex Kornbrust
• Many more such as JTR
• GPU crackers
• - http://marcellmajor.com/frame_cudadbcracker.html from Marcell Major - 200 Million hashes a second
• IGHASGPU - 790 million hashes a second SHA1 cracker - >52 character space would null the speed increase compared to DES
• These can also be used on a limited character set – so SHA1 and 26 characters
• Online crackers exists for some algorithms – such as md5 and DES so can be used for single hashes
• Dennis Yurichev cracker on next slide was on-line BUT NO LONGER

Slide 14 - Cracking – Hardware Crackers

• Hardware crackers – ASIC, FPGA, GPU (Really Software?)
• http://arstechnica.com/security/2012/12/25-gpu-cluster-cracks-every-standard-windows-password-in-6-hours/ - Not Oracle but good example of GPU hardware cluster – 350 Billion guesses a second!
• SHA512 only 364K / sec on same hardware (massively slower)
• Approx cost 25 * £135 + 5 * £600 = £6,375 (my guess on price) + time / dev!!
• http://yurichev.com/ops_FPGA.html - 65 - 85 Million hashes a second – just built and set live, no analysis, no serious tuning
• Because its an FPGA it can be duplicated on other FPGA hardware
• How far can someone go with reasonable costs
• Denis used Stratix II 60k LE; Available: XESS Xula 24K (DIP40 pkg) or De0-Nano-Soc 40K (dual core, 900mhz Arm Cortex A9 running Linux, gig Ethernet) – (Possibly 77K LE if Arm Removed) – all for £67 (chip only £95; hmmm) - £6375/67 = 95 * 60 = 5700 * 1.4M = 7.9 Billion Hashes a second – for the same small money – would get more cards for same price – possibly 1B/hps with tuning for approx £7-800 GBP
• GPU is better value ? we are comparing Windows NT and DES
• ASIC probably would be better for speed, not cost? – would need more work but custom design should always be faster

Slide 15 - De0-Nano-Soc FPGA

De0-Nano-Soc FPGA

Slide 16 - Password Design

• Password design must be scientific
• We cannot simply set a length based on no other factors such as lifetime and complexity of the password
• If we must set a length then we have to design a lifetime and complexity rules
• We also must consider users ability to bypass the rules
• We must ensure that the business does not bypass the rules for some passwords – (often schemas and DBA)
• We must understand how someone could find, steal, crack, subvert passwords and use that knowledge to design strong passwords

Slide 17 - Password Cracking Calculations

Demonstrate different cracker speeds and also keyspaces

Slide 18 - Crackers Can Affect Password Choice

Crackers Can Affect Password Choice

Slide 19 - Profile Design

• Resource fields (e.g. sessions_per_user) need resource_limit to be turned on
• Fields reuse_time and reuse_max should not be used
• In combination they do not work as you imagine
• Better to never allow passwords to be re-used
• The field grace_time is confusing and artificially extends the life time
• The life time must be designed in combination with complexity
• Complexity function must exist to enforce the password
• Lock time must be designed based on use of the account
• Ensure global parameters – case, failed logins also match design

Slide 20 - Profile Design (2)

These are my examples, design your own..

Slide 21 - Password Verify Function

• Use the 12c Core functions in utlpwdmg.sql
• Write your own simple “frame”
• Adding a verify function forces use of “replace” syntax
• Beware that use of ALTER USER IDENTIFIED BY VALUES can bypass password verification
• SQL*Plus password also can bypass rules
• Wrap and protect function

Slide 22 - Conclusions

• Design strong passwords
• Ensure hashes cannot be read
• Ensure strong passwords are properly enforced
• Ensure everyone is involved – e.g. no gaps

Slide 23 - Questions?

Any Final Questions?

Slide 24 - Oracle Database Password Security

An Appreciation