Oracle's Password Hashing

Here’s a paper on Oracle’s password hashing algorithm. It isn’t very good.

In this paper the authors examine the mechanism used in Oracle databases for protecting users’ passwords. We review the algorithm used for generating password hashes, and show that the current mechanism presents a number of weaknesses, making it straightforward for an attacker with limited resources to recover a user’s plaintext password from the hashed value. We also describe how to implement a password recovery tool using off-the-shelf software. We conclude by discussing some possible attack vectors and recommendations to mitigate this risk.

Posted on November 3, 2005 at 1:20 PM23 Comments


Kevin November 3, 2005 1:42 PM


LMAO – I also had to read it twice… at first, I was like, “well, if the paper isn’t very good, then why are you putting it on your blog???”

Greg November 3, 2005 1:44 PM

This is not very suprising. But then with the Databases I have worked on the weakest link is still the ppl. Many high profile databases use single word passwds… and even worse.

Sure theres company policy about passwd etc, but theres always at least a few pll with real bad passwd and/or they give the information to any contractor…..or jsut about anyone.

Moz November 3, 2005 4:39 PM

You guys are just bashing Oracle as usual. You have to read their promises more carefully..

unbreakable: beat it, bash it, trash it: it never ever dies ; killing it is impossible *

  • (only applies to failure of the f45 integrate circuit; and only on sunny days, and only if the user has already executed five headstands prior to login. Any other failure excluded).

Mario November 3, 2005 5:00 PM

Hi Bruce,

what did you mean with:

“… It isn’t very good.”

i) the paper it’s not well written.


ii) the content are bad news for security.


David Magda November 3, 2005 5:50 PM

I’m curious to know why they don’t adopt MD5 hashes or OpenBSD’s Blowfish algorithm. You’d have to do in a a backward compatible way, but given that both are available with very liberal licesnses it’d be dumb not to.

Roger November 3, 2005 8:41 PM

It is an interesting paper, but I think that the claim of “making it straightforward for an attacker with limited resources to recover a user’s plaintext password from the hashed value” is somewhat overblown. Specifically, the algorithm has three weaknesses listed:

a) It smashes case, so you can’t strengthen a password by mixing case.
— This is a problem, but a small one. It simply means that strong passwords should include digits and punctuation marks, and might need to be 1 character longer than otherwise. For example, a 7 character random password that uses upper and lower case, digits and punctuation, has LESS strength than an 8 character one with case smashed.

b) It uses the username as the salt, so the probability of finding accounts on different databases using the same “salt” is much higher than it should be. This causes two main problems:
— If a user has the same account name and password on multiple databases, this fact can be easily identified by an attacker who might choose to focus on such accounts. This is undesirable but not exactly fatal if other good password policies are adhered to.
— More seriously, important account names which can be found on all systems, e.g. SYSTEM, are subject to precomputation attacks. There is an obvious implication/solution to this: the SYSTEM account must have a very strong password. But you already knew that, right?

c) The actual hashing algorithm actually appears to be cryptographically secure, but can be executed fairly quickly, allowing dictionary attacks to proceed fairly fast. I would not actually call this a weakness. In some (very) modern systems it has become the practice to “stretch” passwords by iterating the hash many times to make the operation very slow. For example, I recently implemented a system which uses a “stretching factor” of 10,000 times for unprivileged accounts and 100,000 times for the administrator (who consequently takes 3 seconds to log on), with the ability to gradually increase this factor over time as processors become more powerful. However, this is quite a recent practice and as yet very few systems do it; blaming Oracle for not doing it is not very fair. Furthermore, not having it is not actually a weakness in the hashing algorithm, rather implementing it is an additional precaution against users who choose weak passwords. Choosing strong passwords in the first place would obviate the question.

For example, the authors note that they were able to enumerate all 8 character alphanumeric passwords in 39 days. Okay, a bit faster than I expected buuuut… we have long considered 8 character alphanumeric passwords to be the absolute lowest common denominator for password security. Adding in punctuation as well would already increase this to 21 years! Or keeping to alphanumeric but requiring a ten character password, would push it out to 140 years. Or do both, and even with a 1000 host zombie network it will take more than a century.

In short, standard password advice already overcomes all these weaknesses, with perhaps the caveat that Oracle password minimum lengths need to be about 1~2 characters longer you might otherwise expect.

More of a concern is the number of attacks the authors list which can obtain the hashed passwords in the first place (like /etc/shadow, the opponent is not supposed to even see them in the first place.) Of course, the biggest problem with Oracle passwords is the number that are actually left blank, or set equal to the account name, despite the fact they will only be accessed by a script which can easily use a very strong password…

Peoplesoft user November 3, 2005 10:14 PM

As far as the comment goes about the “sa” account, if this is referring to the standard peoplesoft sa account, it almost might as well be an empty password. Anyone with 2 tier access in Peoplesoft has access to the entire system. Their security model relies on a trusted client which is a faulty model when the client runs on a machine that a not fully trusted user can touch.

Peoplesoft user November 3, 2005 10:26 PM

Sometimes the application using the database can cause problems. For example in peoplesoft there is typically a “sysadm” account with full access to to all of the peoplesoft data. To use Peoplesoft in two tier mode (which is needed by developers for some things) you need to connect to the database using the “sysadm” account. The developer doesn’t typically know that password, but he runs a piece of software that gets it from the database (after initally connecting with a lower privileged account) which then connects to the database for him. This typically happens on a machine controlled by a developer, so it isn’t hard in theory to find out what the password is. This isn’t usually a huge deal, since your developers are usually fairly trusted, but it certainly isn’t a desireable situation.

DavidG November 4, 2005 2:57 AM

“In short, standard password advice already overcomes all these weaknesses”

Will it? For example, you can’t enforce a policy for people to use mixed-case, because even if you did, it would instantly turn it to upper case first.

This is very bad. Although the easiest way to get into most Oracle systems is to log in as system/manager….

NotAnonymous November 4, 2005 3:42 AM

MS SQL Server is particularly bad in this respect. I frequently have to migrate logins between servers. Once I am given an Admin domain account to do all the application-side of things, I bcp out sysxlogins and run a brute force. Then recreate all logins on the new server. So far nobody asked me how I was able to do that. There are procedures for moving the encrypted data, but this way feels safer since it’s all in clear text.

RvnPhnx November 4, 2005 8:47 AM

Ok, this isn’t good and all, but what (in my opinion) is more frightening is that there are people out there whom would run a machine with Oracle on it with the Oracle client communications connection port WIDE OPEN with no firewalling at all.

Roger November 6, 2005 6:33 PM

@David Magda
“I’m curious to know why they don’t adopt MD5 hashes or OpenBSD’s Blowfish algorithm.”

The Oracle algorithm seems to predate MD5 (published 1991) and Blowfish (1993, and — as someone else pointed out — authored not by OpenBSD but by our own esteemed blog author, Bruce Schneier).

Moreover the identified problems are not with the core hash function, but the way it is used. Changing to MD5 or Blowfish but using them in the same way wouldn’t fix anything (with one small exception). The first 2 problems are smashing case (i.e. all letters in uppercase), and badly chosen salts. Both of these occur before the hash is even called and so are independent of it.

The third problem (which arguably isn’t really a defect in the algorithm) is that evaluating the hash is not slow enough, and so they can try many guesses quickly. In this respect, MD5 is worse because it can be evaluated faster than the Oracle hash (~10 times faster for typical password/username combinations, e.g. 13 ~ 16 bytes require 8 DES encryptions vs. 1 MD5 hash). Blowfish is somewhat better in this regard because Bruce deliberately designed the key set-up to be very slow; overall it would be ~20 times slower than the Oracle algorithm. This is an improvement but barely; true stretching should give a slow-down factor of thousands.

Roger November 6, 2005 8:06 PM


“In short, standard password advice already overcomes all these weaknesses”
Will it? For example, you can’t enforce a policy for people to use mixed-case,
because even if you did, it would instantly turn it to upper case first.

Note that my sentence continued “…with perhaps the caveat that Oracle password minimum lengths need to be about 1~2 characters longer than you might otherwise expect.” Provided your passwords are not dictionary words (which is part of standard advice), then increasing the length by 2 characters typically increases the strength by more than that lost by smashing case. In the optimal case of passwords chosen randomly from the whole available character set, an 8 character password chosen from all 96 printable characters has about 2^^53 possibilities while a 9 character one omitting lower case has 2^^55, so even one more character more than compensates for the case smashing [1]. Alarmingly, many sites continue to permit 6 character passwords which should have gone out of style in about 1980. Upgrading them to minimum 8 gives you about 18 more bits which is lots more than lost by case smashing.

Anyway, some additional advice if you’re still worried:
a) Obviously it is pointless to insist on mixed case so instead insist that passwords include letters, digits and/or punctuation marks, preferably randomly chosen from all three.
b) Making user names unique per database will greatly reduce the effects of the weak salts. One way to do this might be to prepend the database name, so that instead of user ‘david’ we have user ‘acme-test-david’. Scripts couldn’t care less about this, while better interactive tools cache the user names used for each database (and the passwords too, if you permit them) so it isn’t much hassle to humans. However it means that the weak Oracle salt is now highly likely to actually be globally unique (except for system level accounts which you can’t change).
c) Conversely, system accounts should either be disabled (if not required) or given very strong passwords (at least 14 characters randomly selected from all available).
d) Try to ensure that the username/password combination is at least 17 bytes. This will increase the attacker’s time requirements by only 25%, but can be done very cheaply if you use long usernames, which is easily achieved through point b) above. Actually by employing point b) above plus 10 character passwords you can easily get the combination to 25 bytes or more, which will increase the opponent’s time requirements by 75%. (Every 4 bytes gives another 25% increment.) Not a huge gain but useful and cheap.
e) Better yet, give all your users Password Safe so they don’t need to remember their passwords, and have a password minimum of 20 randomly chosen characters for all accounts.

Although the easiest way to get into most Oracle systems is to log in as system/manager….

Yes, absolutely. It is distressing to see the number of “Unbreakable (TM)” production grade Oracle databases in large companies which use default passwords (incredibly even including the password “change_on_install”), blank passwords, or passwords equal to the username (which is often the same as a product or project name). In one place I worked, the strongest Oracle password on site, at least the strongest I came across, was a 5 character dictionary word with the ‘i’ changed to ‘1’. The DBAs generally justify this on the grounds of the network admin’s rock solid routing security. Um, yeah, right.

1. Of course 2^^55 attacks are now feasible for very resourceful opponents (c.f. the distributed DES cracking contest) so I now actually consider the minimum to be 10 characters, unless significant stretching is involved. Due to Moore’s law we can presume this minimum will continue to increase at the rate of about 1 character per decade, so I would recommend that all new systems include a stretching mechanism which is capable of gradually upgrading the stretching factor. That is, each password record in addition to the salt and the actual hash includes (say) a 32 bit unsigned integer which says what stretching factor was used, and the password change mechanism checks to see what stretching factor should be used for new hashes. In this way you can increase the stretching to keep pace with your hardware so that logins take roughly constant time as you upgrade the hardware. Since presumably Moore’s law affects attackers and defenders about equally, such a mechanism roughly negates Moore’s law and means that 1970’s grade passwords will remain suitable forever. The required entropy of a password is then determined solely by the ratio between acceptable login delay (say, 1 second for ordinary human operated accounts) and the expected cracking time (say, 1 year for low grade accounts). A ratio of 1 second to 1 year gives an entropy limit of log_2( 2 years/1 s) = 25.9. A single case alphanumeric password hits this with about 5 characters; choosing from all printable characters we would only require 4. Admin accounts could be made slower (say, 5 s) for better protection, while script accounts would need to be faster, but can have much stronger passwords to compensate.

Pete Finnigan November 8, 2005 4:24 PM

Hi Bruce,

I would like to make a few comments on this issue and the above comments if I may. I have been writing about Oracle security for quite a few years now and my site is dedicate to Oracle Security. I agree with Rogers comment that most of the weaknesses are overblown. I wrote about the case issue a few years ago and also the username as salt is known, i have demonstrated this in my writings previously as well. Anyway to the main point; well two actually. If the password is long enough and also uses the full keyspace (minus the Upper/lower case issue) then it would take too long to crack the password using brute force or even to generate rainbow tables. Josh’s rainbow table is only for ascii characters for the user SYSTEM for instance. The main issue is the many many ways that it is possible to get hold of the password hashes. There are available via the base table SYS.USER$ and SYS.USER_HISTORY$, views like DBA_USERS, the data files, full exports, SQL*Plus list files where someone has queried the dictionary and many more.

It is possible to use password management features in Oracle for every user even setting up a password verification function where you can define any valid PL/SQL code to construct complex passwords.

The second biggest problem in Oracle is not the password algorithm but the huge proliferation of default users and passwords. I have listed around 600 on my site – and around another 500 to add to it when I get time.

So, in summary, protect access to the hashes, file permissions on data files, exports, password file and remove access to all dictionary objects that can be used to view hashes. I have a good script that gives a nice heirarchical view of all users that can access objects.

Then use suitable length passwords – I always recommend 12 characters for DBA’s, SYS and SYSTEM and shorter for general users but use the password management features (profiles) and ensure that the full keyspace is used.



Leave a comment


Allowed HTML <a href="URL"> • <em> <cite> <i> • <strong> <b> • <sub> <sup> • <ul> <ol> <li> • <blockquote> <pre> Markdown Extra syntax via

Sidebar photo of Bruce Schneier by Joe MacInnis.