THREAD CROSSOVER WARNING!
The man page is for libc5. glibc2 has a crypt() that recognizes MD5. The
documentation is in libc.info.
>> Wrong. MD5 passwords can be significant to a lot more than 8 chars.
>
>But the standard unix passwd command available on most systems
>(including those flavors of linux I've access to) only accept passwd's
>with eight or fewer characters. On my nice new RH 6 install, it says
>that the new passwd is "too similar to the old one" if I enter 10
>characters none of which resemble those in my old one, but if I enter
>only the first 8 it is happy. Obviously, it uses the DES crypt and not
>MD5.
Whether the passwd command uses MD5 or DES is configurable. If you installed
that redhat 6 yourself, you may remember that one of the last things it asked
you during installation was whether to use a shadow file, and right under
that (or above it? I forget) is the question of whether to use MD5.
If you want to change it later, look for something like this in
/etc/pam.d/passwd:
password required /lib/security/pam_pwdb.so use_authtok nullok md5 shadow
Add the "md5" flag and from now on, passwd will generate MD5 passwords.
>Perhaps the original poster wanted to generate MD5 passwds. On the
>other hand, perhaps he (like me) just wanted to be able to build
>encrypted passwd fields on demand to paste into a /etc/passwd file for
>new users, perhaps in a simple script (I have another variant of the
>same code that generates 1-N RANDOM new passwd's for the same purpose).
Regardless of what the passwd command does, if you are using glibc2, you can
paste both DES and MD5 passwords into /etc/{shadow,passwd}. The crypt()
function knows what to do with both of them.
>> People, don't truncate things before passing them to crypt. It knows more
>> than you do about the right lengths of passwords and salt.
>
>True enough. If you don't truncate the strings at all, (and clean up
>the code so it is buffer safe to protect you from segment faults in the
>event that you enter way too many characters) then you get the following
>behaviour:
>
>gcc -O3 -lcrypt makepw.c -o makepw
>rgb@rgb|T:30>>!./ma
>./makepw frogfrog abcdef
>abi219G9lnw4E
>rgb@rgb|T:31>>./makepw frogfrogfrog abcdef
>abi219G9lnw4E
>rgb@rgb|T:32>>./makepw frogfrogfrog ab
>abi219G9lnw4E
Now try these:
23:18 a0 defiant /home/pacman %./makepw frogfrogfrog '$1$ab'
$1$ab$5QaA5.UYDkUepc57ReItF1
23:18 a0 defiant /home/pacman %./makepw frogfrogfrog '$1$abcdef'
$1$abcdef$u0JTi3SVt4RTys6qBZOqT/
23:19 a0 defiant /home/pacman %./makepw frogfrogfrog '$1$abcdef$u0JTi3SVt4RTys6qBZOqT/'
$1$abcdef$u0JTi3SVt4RTys6qBZOqT/
23:18 a0 defiant /home/pacman %./makepw frogfrogfrogfrog '$1$abcdef'
$1$abcdef$k1q1hqeG2D9z96JUqkzm81
Look at that! Just by taking out the truncation, your program now works
correctly with MD5's long passwords and salts!
>Note that crypt only keeps the first two characters of the salt and
>ignores more than eight characters of the passwd field. Presumably if
Unless the salt starts with "$1$", which is used to signal MD5.
>you have replaced the standard DES crypt with an MD5 version, it will do
>better than this, but when I wrote this little code snippet I didn't
>have the MD5 version installed. I still don't. (IMHO) Most crack
You said you have redhat 6. Unless you're David Parsons in disguise, I find
it hard to believe that you really removed glibc2, so you _do_ have the
MD5-aware crypt.
>attempts succeed not because of the weakness of the DES encryption but
>rather because of the stupidity of users in choosing dumb passwd's that
>are easy to crack. At some point in the not too distant future, of
That is quite true.
>course, we may all need to use MD5 (or any really slow and painful
>variant of crypt) just to slow down the encyption to the point where
>crack cannot exhaustively search all letter permutations, but this was
>not the point of my posting the code snippet -- I was just trying to
>illustrate the use of crypt in a practical frame.
And it was not a bad demonstration, but those salt truncations always bug me
because the crypt function is going to do its own truncation anyway, so you
are really just making your program more complicated than it needs to be.
For verifying a previously existing password, you could make things really
complicated, and write your own check for the $1$ and extract the salt (which
extends up to the next $), and truncate there, in addition to your
2-character DES truncation code... or you could just pass the unmodified
pw_passwd or sp_pwdp to crypt() and let it do the work for you.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/