[9901] in bugtraq

home help back first fref pref prev next nref lref last post

Re: Digital Unix 4 protected password database.

daemon@ATHENA.MIT.EDU (Keith Piepho)
Fri Mar 12 16:32:47 1999

Date: 	Wed, 10 Mar 1999 17:30:10 -0500
Reply-To: Keith Piepho <kap@UAKRON.EDU>
From: Keith Piepho <kap@UAKRON.EDU>
To: BUGTRAQ@NETSPACE.ORG
In-Reply-To:  <199903101747.RAA02324@coyote.uk.sun.com>

At 05:47 PM 3/10/99 +0000, you wrote:

>
>Paul Leyland told me, many years ago, that one or more of the
>"Enhanced Security" crypt-replacements are actually less secure
>than traditional crypt() in many respects.
>
>Consider the:
>
>	crypt first 8 chars
>	crypt remaining 8 chars
>	join the two ciphertexts
>
>...mechanism; assuming people choose passwords which are (a) plain
>dictionary words and (b) only slightly longer than 8 characters, then:
>
>	plaintext = wheatsheaf
>	first 8 chars = wheatshe
>	last 8 chars = af
>
>...the cracker may brute-force the latter ciphertext with its implicit
>small keyspace, and then (eg:) go hunting for words in dictionaries
>which are 10 characters long and whose last characters are "af",
>thereby possibly reducing the search space for the first 8 characters
>*very* significantly.

I think your specific example here is a little off, since it assumes that a
cracker has the encrypted password and a dictionary that contains it.  If
these two suppositions are true, the fight is already over, and you have
lost.

Focusing on the case in which the password is a dictionary word obscures
the real problem:  to compensate for the insecurity of an 8 character
password, DEC has replaced it with what appears to be a 16 character
password scheme, but is in reality just 2 8 character passwords, doubling
instead of squaring the size of the keyspace that must be searched.  (and
much less than doubling, in the case of the all-too-frequent short second
keys which will occur.)  Nothing like the illusion of security to keep the
managers sleeping soundly at night.

The alternate scheme you mention (in the part I cut) of encrypting the
first 8 characters and the last 8 seems to me to result in a 16 char
keyspace.  Clever.


	-- - keith
--
Keith Piepho                    kap@uakron.edu
Technical Services              (330) 972-6130
The University of Akron

home help back first fref pref prev next nref lref last post