Hello:
Raju Mathur wrote,
> Don't know if that `standard' Linux distributions support Blowfish
> encryption for password.
The crypt libraries do have blowfish support but i don't see any
application support for it. Linux PAM at least does not seem to
understand blowfish.
Raju, which is the preferred password hashing algo for "new"
applications if i don't want to maintain backward compatibility with MD5
based hashing schemes, SHA1 or RIPEMD-160?
IAC, I have moved my backend to Kerberos! :)
> Though it's true, as far as I know the $n$
> string at the beginning is supposed to tell the password matching
> routine which algorithm to use to hash the user-supplied string.
K
> Shanker> Then again, i think this password hashing business is all
> Shanker> screwed up.
>
> Shanker> For example, on my recompiled slapd with --tls, auth
> Shanker> fails if i use "$1$somesalt$therest" passwords in the
> Shanker> userPassword attribute. Without TLS, the same hash works
> Shanker> for authentication.
>
> Umm, I very much doubt that it's due to different routines -- such an
> issue would have been noticed and solved years ago. What's more
> likely is that compiling TLS in changed the default auth method. Just
> a guess.
Well, I did ask around in the OL lists and thats what [EMAIL PROTECTED]
had to comment on this issue.
The best part is, this TLS + slapd issue is happening only on my Debian
boxes, the slapd on FreeBSD and RHL have no probs whatsoever.
> Shanker> Apparently, the Linux glibc crypt() function is not
> Shanker> exactly the same as the OpenSSL crypt() function,
> Shanker> depending on the order in which you link -lcrypto and
> Shanker> -lcrypt, you might end up with strange results.
>
> Shanker> Sadly, I cant read C code to ascertain for myself! :(
>
> I can, but reading OpenSSL code wouldn't be my favourite way of
> spending a few hours :-)
He He.
> Shanker> As i understand it:
>
> Shanker> - Plain crypt is MD5 with a 2 char salt. This is what the
> Shanker> PHP (and Perl IIRC) crypt function provides if no salt is
> Shanker> passed to the function.
>
> crypt(3) uses a 2-character salt, as you say, and DES, not MD5 as the
> hashing algorithm. OpenSSL has a set of DES routines which can run in
> MIT (presumably traditional) crypt compatibility mode. IAC, the
> passwords you have ($n$salt$password) are definitely MD5, not crypt
> passwords.
Right.
> Shanker> - Linux/FreeBSD style password hashes use $1$ and an 8
> Shanker> char salt. Depending on the salt, the Perl/PHP crypt
> Shanker> functions hashed output will change.
>
> >> $1$eYrvxTAm$Wz4Wkxe5exy/5VhkuTnYH0 for example - 34 chars long,
> >> so neither base64 nor hex. So, when you try using courier imap
> >> or vpop3d on linux with (say) exim on linux ... and try to
> >> verify courier passwords by throwing them at crypt().
>
> Shanker> I don't think that will work. You will have to throw in
> Shanker> the salt part to the crypt function as well.
>
> Uh, these are MD5 hashes and as such not compatible with crypt. Use
> the OpenSSL MD5 functions to hash and base64 to convert to ASCII. The
> hash is actually the MD5 hash converted to base64.
Raju, thanks a lot for clarifying.
-- Shanu
--
Perhaps Debian is concerned more about technical excellence rather than
ease of use by breaking software. In the former we may excel. In the
latter we have to concede the field to Microsoft. Guess where I want to go
today?
-- Manoj Srivastava
_______________________________________________
linux-india-help mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/linux-india-help
