Oracle 11g Password Algorithm Revealed
It’s based on SHA-1.
Comments
Tom Womack • September 28, 2007 8:02 AM
The known SHA-1 vulnerabilities are collisions rather than preimages – nobody, as far as I know, has managed to find a message with a previously-given md4sum, let alone the stronger md5 or sha1.
I suppose for advertising reasons I’d be tempted to use SHA256 in a new password hash, but I don’t think I’d be gaining more than an advertising point thereby.
SteveJ • September 28, 2007 8:32 AM
More worrying, if it’s true, is this:
a major flaw exists in that the older 10gR2 and lower algorithm is also still used and the SYS.USER$.PASSWORD column still contains the lower version case insensitive password.
Never mind whether it’s SHA-1 or SHA256, what’s the point of hashing your password with 80 bits of salt, if you also store it ROT-13 in the same database row?
supersnail • September 28, 2007 8:38 AM
According to good old wikipedia you can find a collision for SHA-1 in 2 to the power of 69 operations. This probably translates to about 5 to 10 thousand days of processing on a modern cpu.
Sounds good but some botnets have more than 5000 slaves so Dr. Evil could probably crack this in a week or two.
Worse databases usually have considerably more than one user defined, so if a databse has 1000 users defined you will find a usable collision in one thousandth of the time.
Oracle should have taken the oppertunity to beef up thier security in release 11 — but until they start losing sales over hacked databases I doubt if they will bother any time soon.
Jonadab the Unsightly One • September 28, 2007 8:59 AM
I suspect a significant contributing factor to Oracle’s view of security is the notion that the RDBMS should normally be deployed on a network segment where any access at all is somewhat controlled (which, granted, it generally should be). Good defense in depth, obviously, would mean that the RDBMS itself still should be as secure as (reasonably) possible, but probably the largest threat (to the security of the data stored in the database) in such instances is the possibility of an inside job, in which case the majority of the blame probably isn’t going to be placed directly on the DB vendor, because people are generally going to ask the wrong question.
The right question would be something along the lines of “What could have been done to make this attack more difficult to pull off?”, but people are much more likely to ask simply “Whose fault was this?” and stack the blame on the shoulders of the inside man or his direct supervisor. That’s not really very logical, but it’s how people usually think.
Andre LePlume • September 28, 2007 9:04 AM
If only there were something like a future adaptive password scheme specifically designed to keep up with hardware advances, and having a hash algorithm suffering from none of the disadvantages of SHA-1.
Oh, wait…there has been since 1999.
http://portal.acm.org/citation.cfm?id=1268740
Paeniteo • September 28, 2007 9:47 AM
@supersnail: You are confusing findung collisions with a preimage attack.
The latter is required to find the password to a known hash and it is per se much more difficult than finding a collision (i.e. finding two password with the same hash – but without a possibility to predict or influence the hash vaule).
Furthermore, the published attacks on MD5 and SHA-1 do not work for preimage attacks.
Fin • September 28, 2007 9:55 AM
Sorry if I’m being dumb but wouldn’t rainbow tables be a better attack than trying to compute collisions? Why not just attack using the known hashes and the SHA1 rainbow tables? With more than a few users you’d get matches on a standard rainbow table.
If I have completely missed the point then apologies.
-ac- • September 28, 2007 10:00 AM
It would be a spectacular feat indeed to find two user-friendly passwords that had the same hash. I’m not holding my breath. A collision is fine, but usually entails using exhorbitantly long data (text/PS file, etc) and making mods to corrupt it yet keep the same hash.
Pegr • September 28, 2007 10:11 AM
Rainbow tables would work on the older password hash, I believe. The salt is what kills that approach for the newer SHA1 hash. You’d need a set of rainbow tables for each hash value.
Pegr • September 28, 2007 10:11 AM
Rainbow tables would work on the older password hash, I believe. The salt is what kills that approach for the newer SHA1 hash. You’d need a set of rainbow tables for each salt value.
Nicko • September 28, 2007 10:32 AM
@supersnail
Not only is Paeniteo right that you’re looking at the cost of a collision attack, not a pre-image attack, but I also think your calculation is off by a few orders of magnitude. “5 to 10 thousand days” is about 2^29 seconds, so your “modern cpu” would have to be able to compute 2^40 SHA-1 hashes a second. A full block of SHA-1 processing is about 1,000 clock ticks on a modern CPU so to get the performance you describe you would need a 1,000,000 GHz CPU!
Anonymous • September 28, 2007 10:41 AM
@Jonadab, true that defense in depth is a key part of this, the attach would need to be mounted within the controlled network environment. Not entirely true that the wrong question would be asked, and the right question ignored. Both would, and should be asked, and fault most likely would extend to the inadequacies in the environment that allowed the attack to succeed without detection in time to forestall it.
btw I am presently looking into the security of a critical Oracle database for the financial institution where I work, and this discussion is very helpful and relevant to my job. Thanks to all!
sooth_sayer • September 28, 2007 11:07 AM
This is not totally uncommon and unexpected. What did you expect a system to do.
The only possible “key” is a user chose pw, that most user won’t remember unless it’s 8 or less chars, user name is a quasi secret due to standard addressing/naming schemes – the salt is totally useless, it add’s nothing to security ..except some idiot might think it makes the hash taste better (more secure).. well it’s not a hash brown.
This, to me is not a news except orcale could have used SHA2 with about 30 minutes of programming work. These are dumb decisions that companies regret after being exposed .
dragonfrog • September 28, 2007 12:03 PM
@Pegr
Yes, the older scheme would fall to rainbow tables.
The newer scheme is vulnerable to heuristic or bruteforce approaches, because SHA-1 is so fast. Proper modern password hashes are designed to be slow, so an attacker is limited in how many tests he can run per second. SHA-1 is designed to be very fast, which makes it unsuitable for a password hash (despite that people use it that way all the time, and think they’re doing the right thing because they use salted hashes)
Chuck • September 28, 2007 12:38 PM
Two things:
First of all, if you can see the SYS.USER$.PASSWORD table, you already have superuser (DBA) privileges.
This is equivalent to saying that the root user in Unix can see encrypted passwords. Who cares? If you’re root, you don’t need any other password.
Second, it amazes me that a 2007 release of Oracle does not support SHA2 hashes. Didn’t the NIST ask us all (in the US) to move to SHA2 years ago? Why isn’t Oracle doing this?
Randall • September 29, 2007 4:11 PM
Key stretching could’ve been somewhat useful — but it’s too hard to remember good passwords even with help.
SHA-2 support is nontrivial because Oracle would have to worry about backwards compatibility.
As a non-Oracular DB person, I’m curious what kind of challenge-response auth they have.
As a fun hack, some clients could store the salted, hashed, and possibly stretched password rather than an obfuscated cleartext one, the advantage being that it’s harder to use the former to log in to other systems where the same PW’s used.
spenser • December 10, 2007 3:38 AM
Once more the reasoned voices here have saved some grief.
Not being a crypto person, or even a mathematician, it was a relief to find that there is a difference between a collision and a pre-image attack/failure.
Why? Because I want to recycle my prehistoric SHA-1 code in a new system for web user authentication in non-critical systems. Since it exists in a number of production implementations for script, binary and SQL compatibility, this saves a bunch of work and testing.
At the very least, this page can be a resource for those who have read about the collision problem and need to evaluate it’s real impact, given that the assets being protected have low value.
Subscribe to comments on this entry
Leave a comment
Sidebar photo of Bruce Schneier by Joe MacInnis.
Ozan Ozkara • September 28, 2007 7:39 AM
SHA-1 algorithm vulnerabilities was already disclosed.