Hello,
[ Aleph1, I am not sure if this discussion of old mistakes belongs
here; however, it is useful to learn on them, and I am including a
few facts that I consider funny enough, below. ]
> Paul Leyland told me, many years ago, that one or more of the
He has also posted one implementation based on UFC, to BugTraq in 1995.
> "Enhanced Security" crypt-replacements are actually less secure
> than traditional crypt() in many respects.
Yes. At least two of them, actually.
The Digital UNIX one (BTW, I've also seen it on a SCO box) works like
this (in pseudo-code):
strcpy(hash, traditional_crypt(pw, salt));
if (strlen(pw) <= 8) return hash;
strcat(hash, traditional_crypt(pw + 8, hash + 2) + 2);
return hash;
(According to an old manpage, this might be extended for longer
passwords as well in reality, but I've never seen those.)
While the Ultrix one is different (and is even less secure):
strcpy(hash, crypt_x20(pw, salt));
strcat(hash, crypt_x5(strlen(pw) > 8 ? pw + 8 : "", salt) + 2);
(Here crypt_xN means the traditional crypt(3) modified to have only
N iterations of DES instead of 25.)
To summarize, the attacks pointed out in previous posts apply to
both; however, it should be noted that for the Digital UNIX one at
least the salts are typically different for the password halves,
and that, on the other hand, even more attacks are possible on the
Ultrix one.
For example, a cracker could work like this:
-- take either the next word or its characters past 8;
for each salt:
-- do 5 iterations of DES, compare against the second halves;
-- do 15 more iterations, compare against the first halves;
-- move to the next salt.
While the Ultrix version always produces 24 character long hashes,
it is still possible to detect if the password is longer than 8
characters or not. One fast way is to generate a table of second
halves for all the 4096 salts; there's, however, a nicer fast way
that utilizes the properties of DES (namely, the fact that a zero
key is "weak"). The trick is that subsequent DES encryptions with
a zero key undo each other, and thus 5 encryptions are equal to 1.
I am supporting the Digital UNIX (and SCO?) version in John, by
splitting the halves at loading, and combining the cracked ones
back when reporting, thus getting some extra matching salts.
In case this gets to the list, -- is there still any demand for
checking the Ultrix version's passwords, despite the fact that it
would be wiser to switch to a better crypt(3)? (I've got a few
requests in the past, actually.)
> | <printf> <aa> <aaCjFz4Sh8Eg2QSqAReePlq6>
Checking the pseudo-code above, on a system with extended DES-based
crypt(3) (BSDI, OpenBSD):
$ perl -e 'print crypt("printf", "_I...aa..") . "\n"'
_I...aa..CjFz4Sh8Eg2 <-- got the first half correctly
$ perl -e 'print crypt("", "_3...aa..") . "\n"'
_3...aa..QSqAReePlq6 <-- the second half, 5 iterations
$ perl -e 'print crypt("", "_/...aa..") . "\n"'
_/...aa..QSqAReePlq6 <-- plain DES, no iterations needed
Signed,
Solar Designer
This archive was generated by hypermail 2b30 : Fri Apr 13 2001 - 14:39:03 PDT