If you are a security developer and need to interface a Java application with the local operating system user registry, what do you do? This article gives you the answer: UNIX/Linux PAM-compatible systems that use authentication based on the GNU MD5 extensions to the crypt() system call. A pure Java implementation of MD5 crypt can provide a simple interface that can be used by Web applications to authenticate against the local UNIX registry.
Secure Java Apps on Linux Using MD5 Crypt
About The Author
Eugenia Loli
Ex-programmer, ex-editor in chief at OSNews.com, now a visual artist/filmmaker.
Follow me on Twitter @EugeniaLoli
…is MD5 really still considered secure? I thought someone had found collisions already. Yes, yes, a proof of concept is far from a feasible exploit, but still…
collisions dont matter – as long as you dont know the resulting hash and you dont allow more than a limited number of attempts
I think that you even have to have the original string. Without that you won’t find any collisions. Using it to secure something is not a problem, it’s a problem if you use it to controle if something is the same, where the source is available.
IIRC the MD5 extensions for crypt(3c) did NOT come from GNU they were first implemented in FreeBSD. This is is why when I extended crypt(3c) in Solaris to support that and the BSD Blowfish algorithms we referred to crypt(3c) plugins as crypt_bsdmd5(5) and crypt_bsdbf(5).
I also don’t see any where this actually uses PAM despite it being mentioned in the abstract. Sure the some of the PAM modules on systems that use PAM may call crypt(3c) or md5_crypt().
As for the comments about MD5 security from DevL. All of the attacks on MD5 have been for single pass, the use of MD5 in this context actually uses multiple passes through the MD5 algorithm with other mixing and entropy as well. This is quite a different problem space to finding collisions of a single pass of MD5.
For an alternative use of MD5 in a crypt(3c) plugin that is even more “mean” to password cracking, written by Alec Muffett author of Crack and myself (almost of of the algorithm is Alec’s work) see the source to crypt_sunmd5 on opensolaris.org.
Finally I actually think what the author is recommending is a really bad idea. The UNIX login password stored in /etc/shadow is exactly that the UNIX LOGIN password. Since Web applications aren’t creating login sessions to the system they really shouldn’t be using that password database. Being able to read the password out of /etc/shadow requires that the web application be running with some sort of privilege (either euid=0 or in Solaris file_dac_read). Finally just because you have the crypt(3c) algorithm now in Java where were you getting the getspnam(3c) data from to do the string comparison with the hash you get back from crypt(3c) ?
All in a very poor article in my opinion.
Yes, a very poor article.
Assuming you do have priviliged access, as highlighted by Darren, it still can’t see users from other user databases, NIS/LDAP etc. Which IS what PAM can do for you.
I struggle to see the point into whole article.
This is a very poor article. You shouldn’t be writing application code that parses /etc/passwd and /etc/shadow anymore. If you need to authenticate a user in a Java application, you should use JAAS, the Java framework designed specifically for that. It includes an abstraction layer that insulates you from OS-specific mechanisms (like, say, differences in the Linux and Solaris MD5 crypt algorithms). It also lets you plug in Kerberos, LDAP, and other authentication systems without recompiling your code.
To accomplish user auth on a Unix box, use the UnixLoginModule that Sun ships with their JVM.