Oracle FAQ Your Portal to the Oracle Knowledge Grid
HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US
 

Home -> Community -> Usenet -> c.d.o.server -> Re: Be an ontruder: Intrude on Oracle panties the OMLETiclios way, the front door!

Re: Be an ontruder: Intrude on Oracle panties the OMLETiclios way, the front door!

From: hpuxrac <johnbhurley_at_sbcglobal.net>
Date: 19 Aug 2005 14:34:42 -0700
Message-ID: <1124487282.651870.149830@g47g2000cwa.googlegroups.com>


DonBurlesonIsASackOfManur wrote:
> 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 may be wrong but didn't we think omelet had passed away? Received on Fri Aug 19 2005 - 16:34:42 CDT

Original text of this message

HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US