Slashdot Mirror


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).'"

4 of 25 comments (clear)

  1. Re:MD5 is obsolete. by Karma+Farmer · · Score: 2, Insightful

    I'd suggest using SHA256 instead.

    In the open source world, "suggestions" come in the form of "source code."

    Messages written on anonymous message boards aren't "suggestions," they're "idle chit-chat."

  2. JAAS? by icklemichael · · Score: 4, Insightful

    I don't understand why I would do this rather than just use JAAS (which has been part of the jdk since 1.4).

    http://java.sun.com/products/jaas/

    This already handles authentication against unix logins, or windows logins, or pretty much anything else!

    The article finishes with:

    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.

    I have two things to say:

    1. If your app server doesn't support authentication against local OS users (and this is what you want) get a new one.
    2. It is big and clever to write your own authentication system for web apps in 2006.

  3. SRP is the right approach to passwords by Paul+Crowley · · Score: 3, Insightful

    MD5 is not the problem. The trouble with using a system like this is that if you can be fooled into trying to log in to the wrong server, then they can capture your password, because it has to be sent in a form the server understands and can verify against.

    The right approach is something like SRP, which uses your password to negotiate a secure tunnel, in such a way that anyone who doesn't have the password, and doesn't guess it correctly during the negotiation phase, doesn't learn it and can't even take a new guess until next time there's a login attempt. This means that even relatively weak passwords gain a lot of security, because it's easy to limit the number of guesses the attacker is allowed.

    If ssh used SRP, then you wouldn't have to worry about whether the remote host key is right, or whether it's changed - the fact that you manage to negotiate a proper session with them using your password means that they're a legit host.