Message-ID: <20050824195905.1A56718114@olive.qinip.net>
Date: Wed Aug 24 20:59:20 2005
From: jeroen at isvet.nl (Jeroen)
Subject: HOWTO: Crack Oracle Security like a peanut?

Hi there,

Recently, I found this posting:

//---------------------------------------------------------------
Oracle's Password Transform

Goals:
 - Authentication information ("encrypted password") shall be portable
   between machines with different character sets (ebcdic and ascii).
 - It should handle non-enlish languages including those that require
   16 bits per character.
 - If a user has the same password on two databases, the authentication
   information will be the same on both machines.
 - It should be hard to tell if two users have the same password.
 - The password transform should be as hard to break as DES.

The Algorithm:

Convert user name and password to uppercase 'normal' form.  Normal form
uses 16 bits to represent each character, and it is independant of
language
and the computer's character set (acsii or ebcdic).

Concatenate normalized user name and password.  Pad result to multiple of
64 bits.  Zero padding is better than some rolling xor algorithm, since
the
later produces redundant information that an attacker can use to
check for the correctness of a guess.  The result is called UPLONG.

Compute cryptographic checksum of UPLONG using a known key and the cipher
block chaining mode of DES.  The known key is hex 0123456789ABCDEF.  The
idea is to extract 56 suitable bits from the password.  The CBC64 (cipher
block chain with 64 bit feedback path) checksum makes good use of the
bits
in a long password, and it speads out the redundant information that is
present due to the fact that the 'normal' form uses 16 bits per
character.
The feedback path is 64 bits, not the standard 8 bits because it
generates
a more uniform distribution.  See Alan T. Sherman's PhD thesis (MIT 1987)
for justification.

It isn't hard to invert the checksum we just found (the key is known), so
now we hide this result by using it as the key to compute another
checksum
on the uplong array.  That checksum will be used as the authentication
parameter for the user.  Note that DES has the property that given a
matching block of plaintext and ciphertext is is still quite hard to find
the key that mapped the plaintext into the ciphertext.

We could use the first checksum as a key to encrypt a constant, but it
seems safer to use non-constant data like the information in the UPLONG
array.  If nothing else this makes a dictionary attack harder.

Note that an attacker must now solve two simultaneous equations for P:

        k1 = checksum( k0, U || P )
        k2 = checksum( k1, U || P )

Where 'U || P' is the username concatenated with the password (U is
known,
P is not), k0 is the known key, k1 is the first checksum, and k2 is the
value placed in the authentication table.

Convert the second checksum value into a machine independent form.
Since we are not short on characters, express it as a hex string.
//---------------------------------------------------------------

I can reproduce the things mentioned for user/pass-combinations sized 64
bits. For larger combinations (> 64 bits ---> 2 or more 64 bits DES blocks)
I can't figure out yet how things work. Have some of you guys 'n girls
already played around with this description? And are you willing to share
results?

Thanks,

Jeroen

Powered by blists - more mailing lists