Secure Java Apps on Linux using MD5 Crypt

An anonymous reader writes "If you are a security developer and need to interface a Java application with the local operating system user registry, what do you do? IBMDeveloperWorks gives you the answer: 'UNIX/Linux PAM (Pluggable Authentication Module)-compatible systems that use authentication based on the GNU MD5 extensions to the crypt() system call. It will describe these extensions and show you a Java implementation of MD5 crypt (using FreeBSD as my UNIX).'"

Comments

MD5 is obsolete.

[mellon]

If you try to push a protocol in the IETF that depends on MD5, they won't let it through, because it's too risky. So this doesn't seem like very good advice. I'd suggest using SHA256 instead.

Re:No shit?

[ultranova]

For years now, Linux systems have stored their passwords into a file "/etc/shadow", which cannot be read by nonroot users. Therefore, in order to get the MD5 strings (which is a requirement for using those MD5 collision weaknesses for anything), you first need root access; but if you have root access, you don't need the passwords anymore, since you can do anything, including creating a new account with userid 0, making it basically an alias for root.

The MD5 method's real advantage is not that MD5 itself was hard to crack; it is that the whole password, as opposed to just the first 8 characters, are significant. The old method snipped the password internally atfer 8th character; the new one doesn't. Or so the article says anyway.

Re:MD5 bashers, RTFA please

[swillden]

The original crypt() used DES, and GNU later improved it to use MD5. The fact that both of them are outdated and insecure by current standards is not relevant from TFA's point of view.

Just a clarification: neither DES nor MD5 are "insecure".

The 56-bit key size used by DES is inadequate, but the algorithm itself is still well-respected, and the small key size issue can be addressed with multiple encryption, like 3DES.

MD5 has been partially broken, but the collision attacks that have been found have no impact on the utility of MD5 for password hashing. It's still perfectly adequate for that purpose, and for many others. Based on the notion that the existing break might someday lead to a pre-image attack (and on the fact that collisions attacks are problematic for some uses of hash functions), the recommendation in the security world is to use something else, probably SHA-256, or maybe Whirlpool. But it's a big step from a collision attack to a pre-image attack. There are lots of systems that use salted MD5-hashed passwords and there's no rush to change them because MD5 is still perfectly adeqate for that application.

However, I wouldn't recommend actually using the article's technique, for two reasons.

1. Shadow passwords. Most systems use shadow passwords, which means you have to be root to get access to the MD5 hashes you want to validate against, or you have to use a setuid-root helper (which is what pam_unix.so on Linux does). So just about anything you can do to gain access to the database of hashes is a potential security hole. Bad idea.
2. Limited and inflexible. Since this authentication is done in a Linux context, it should really be done via PAM. An application that is written to explicitly validate MD5-hashed passwords from /etc/passwd or /etc/shadow can break in many, many ways. Suppose the hash algorithm is changed? Authentication breaks. Suppose the file layout is changed? Authentication breaks. Suppose the password data is moved to LDAP or to a database (MySQL or such)? Or NIS or YP is implemented? Authentication breaks. Suppose authentication is performed by a RADIUS server? Authentication breaks. Suppose a one-time password token system is introduced? Authentication breaks.

No, rather than doing what the article describes, if you want to authenticate against the system user database, you should do it via PAM. I believe the Java Authentication and Authorization Service already provides a cross-platform API that, on PAM-enabled systems, uses PAM to authenticate. That way, the application will work fine with any of the hundreds (thousands?) of different PAM configurations that an administrator may care to implement.

PAM is very cool, and very powerful, and you shouldn't lightly choose to ignore it. As an example, consider a PAM module I wrote recently.

My module allows a smart card to provide the passwords for authentication. It doesn't do much, just retrieves a password from the card (either static or dynamic "one-time", depending on the configuration) and stores it in the appropriate data structure so that later PAM modules in the stack can use it to authenticate the user.

Simple enough, right? But look how nice this is:

1. The smart card won't provide the passwords until the user has authenticated with the smart card password. My module checks to see if the card is in the "authenticated" state. If not, it prompts for a password if it hasn't been given one already. So in the case where the card has already been authenticated, the user doesn't need to type anything. As soon as the card is reset (e.g. removed from the reader), it loses its authentication state.
2. The smart card also knows the user name, and the module retrieves it, so there's no need for the user to type that in.
3. Since the module doesn't do authentication itself, only provides passwords, it can be used with any other PAM module to perf