shadow MD5 hashed passwords

[Ralph Grothe]

Hello,

though the following was exercised on a Linux box (in which case the ITRC Linux Forum would have been the right place to post this, but attention here seems higher ;-)
I hope the HP-UX Forum is equally suited,
especially since HP for quite a while now have been issuing a supported shadow passwd depot for HP-UX, if I remember correctly.

Actually, my main objective is to provide MD5 or SHA hashed password strings for a Tomcat, rather than storing clear text passwords in the notorious tomcat-users.xml file.
But before this is going to work I will have to assure that my hash strings are encrypted correctly.
So I just use /etc/shadow entries for comparison here.

From man shadow I read that a leading $1$ indicates that the following hash wasn't produced by (DES) crypt() but MD5 algorithm instead. It also reads in the manpage that the used characters must be out of the Base64 character set.

So I compared with this user account

# getent shadow nagios|cut -d: -f2
!!

i.e. no passwd set, so let's set it to "nagios" likewise

# passwd nagios
Changing password for user nagios.
New UNIX password:
BAD PASSWORD: it is based on a dictionary word
Retype new UNIX password:
passwd: all authentication tokens updated successfully.

# getent shadow nagios|cut -d: -f2
$1$jhHJZ.FL$XTPM.rY2UlDsJL6lhbmrj0

But when I try to reproduce this (aided by a handy Perl module) I get a totally deviating hash.

# perl -MDigest::MD5=md5_base64 -le 'print md5_base64("nagios")'
DrCjjPvPd5heTSgbeMwzNg

I also copied and pasted this string while editing /etc/shadow manually.
But of course this didn't work when trying to login.

[Steven E. Protter]

Shalom,

There are some really hot Linux people in the Linux forums that don't read this forums.

I've looked at the shadow password depot for HP-UX. It appears to function like Linux.

I'm not sure about the dictionary check because that comes from cracklib, which is a Linux utility that checks passwords for dictionary words. It even nails commonly used Hebrew phrases.

You seem to be trying to duplicate functionality in a script that is provided through standard system commands like passwd, which is already wired into crack with appropriate encryption.

SEP

[Matti_Kurkela · Accepted solution]

The encrypted password string is not just a simple MD5 hash of the password: it also contains a "salt" value which is generated randomly each time a password is set. If the salt was not used, attacking the password encryption would be much easier.

Without the salt, any possible password would only have exactly 1 matching encrypted form. It would be easy to pre-calculate a dictionary of encryptions of most common passwords.

With the 8-character salt, any password has 64^8 = about 280 000 000 000 000 possible encryptions: for an effective dictionary attack, the dictionary would have to list all the possible forms _for each password candidate_.

"man 3 crypt" has this in the NOTES chapter:
-------------
Glibc Notes
The glibc2 version of this function has the following additional features. If salt is a character string starting with the three characters "$1$" followed by at most eight characters, and optionally terminated by "$", then instead of using the DES machine, the glibc crypt function uses an MD5-based algorithm, and outputs up to 34 bytes, namely "$1$$", where "" stands for the up to 8 characters following "$1$" in the salt, and "" is a further 22 characters. The characters in "" and "" are drawn from the set [aâ zAâ Z0â 9./]. The entire key is significant here (instead of only the first 8 bytes).
-----------

In most Linux systems, the actual authentication happens through the PAM libraries (usually libpam_unix.so), making the code in glibc redundant.

Some Linux distributions (e.g. Debian) offer a libpam_unix2.so library, which can use the Blowfish algorithm in addition to MD5. If Blowfish hashing is used, the password has a leading $2$.

MK

[Ralph Grothe]

Hi Matti,

from having used the Perl implementation of (DES) crypt several times I knew about the existence of the salt.
I was simply using the wrong Perl module.
Whereas, this one encrypts the string as found in /etc/shadow

# getent shadow nagios|cut -d: -f2
$1$jhHJZ.FL$XTPM.rY2UlDsJL6lhbmrj0

# perl -MCrypt::PasswdMD5 -le 'print unix_md5_crypt("nagios","jhHJZ.FL")'
$1$jhHJZ.FL$XTPM.rY2UlDsJL6lhbmrj0

Thanks for the reminder.

Btw, do you know what kind of encrypted string the tomcat-users.xml file would expect?
In the example I've found so far in my Apache Tomcat book it looks like a hex string,
but no separator that would identify a possible salt substring.

[Matti_Kurkela]

Hmm. Apparently Tomcat does something other than "Unix-style MD5 password hashing".

See:
http://tomcat.apache.org/tomcat-5.5-doc/realm-howto.html

Apparently this command would produce a hashed password that would be appropriate for Tomcat:

java org.apache.catalina.realm.RealmBase \
-a {algorithm} {cleartext-password}

(Disclaimer: I don't currently maintain any Tomcat installations beyond the OS level. This information was gained by Googling with "site:tomcat.apache.org tomcat-users.xml" and eyeballing the first few hits. Not tested in any fashion.)

MK

[Ralph Grothe]

Sorry, for bothering you Matti.
Too kind of you to refer me to the Tomcat Realm Doc.
I will be reading this and hope that I will find the answers there...

Regards
Ralph

[Ralph Grothe]

Addendum,
after having listed the contents of all Tomcat supplied jar files in a loop and parsed for the missing class definition error messages by the JVM on invocation iteratively, I finally arrived at the required classpath in order to successfully submit the stated method call to produce password hashes suitable for Tomcat.
Why didn't the authors of the Tomcat Realm Doc mention which classpath the method invocation would require?
Here is what finally worked for my particular Tomcat installation:

$ /usr/java/jre1.5.0_12/bin/java -cp /var/www/tomcat/current/server/lib/catalina.jar:/var/www/tom
cat/current/bin/commons-logging-api.jar org.apache.catalina.realm.RealmBase -a sha secret
secret:e5e9fa1ba31ecd1ae84f75caaa474f3a663f05f4

[Ralph Grothe]

Btw, unlike the salted Unix MD5 password hash
this Java method merely produces an ordinary hex MD5 digest, as can be seen from comparison to the Perl Digest::MD5::md5_hex() invocation.
Oh my, I rather prefer Perl's ease and terseness.

$ /usr/java/jre1.5.0_12/bin/java -cp /var/www/tomcat/current/server/lib/catalina.jar:/var/www/tom
cat/current/bin/commons-logging-api.jar org.apache.catalina.realm.RealmBase -a md5 secret
secret:5ebe2294ecd0e0f08eab7690d2a6ee69

$ perl -MDigest::MD5=md5_hex -le 'print md5_hex(q{secret})'
5ebe2294ecd0e0f08eab7690d2a6ee69