As far as I know, extended crypt is obscure and hasn't been used
much (?).
OS X uses the FreeSec libcrypt, which does recognize the extended
format, and slowly. So does the standard libcrypt on FreeBSD 4.4, where
it is also slow. The Linux 2.4.4 boxen I have seen do not support
extended, or at least there are no details on the crypt man pages or the
source that I can see.
My guess is that the Linux box you're using isn't actually processing
the extended form as extended. A "normal" crypt will just treat the
underscore as part of the salt, and you'll see this in the encrypted
pass since the first two chars represent the salt.
Interesting dilemma, though; you can either compile a new libcrypt or
build a new password list. :-)
- Dan
On Tuesday, June 25, 2002, at 08:48 PM, Gary Blackburn wrote:
> I'm working on a Perl program that does some basic UNIX password
> authentication via crypt. My code works just fine using "traditional"
> crypt. However, the password data I have (I'm making changes to a
> system that manages a big .htpasswd file on a Linux box) all start with
> an underscore, and according to the OS X manpage this is triggers the
> "extended" syntax.
>
> Shouldn't matter too much, right? Well, traditional crypt takes a
> fraction of a second to complete on my B&W G3 300. Extended crypt takes
> upwards of 50 seconds (!!!) to complete the program below. The
> ProcessViewer shows Perl at 90% of my CPU during that time. Yikes!
> This same program responds instantaneously on the production Linux box
> (which probably has a different version of crypt compiled.)
>
> I can live if crypt isn't portable from Linux to OS X (meaning the
> passwords won't crypt the same way with the same salt on both
> platforms) but this speed thing is wretched.
>
> Has anyone else seen this? Is there anything to be done? Thanks!
>
> ---
> Gary Blackburn
> [EMAIL PROTECTED]
>
>
> #!/usr/bin/perl
>
> $string="password";
> $salt = "_lkVkb77CojGo";
>
> if ($salt eq crypt($string, $salt)) {
> print "$string Matched!\n";
> } else {
> print "Nope!\n";
> }
>