Slashdot Mirror

← Back to Stories (view on slashdot.org)

Secure Java Apps on Linux using MD5 Crypt

Posted by ScuttleMonkey on from the handyman's-corner dept.

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

25 comments

  1. No shit? by 19thNervousBreakdown · · Score: 1, Insightful
    http://it.slashdot.org/article.pl?sid=05/11/15/203 7232 http://it.slashdot.org/article.pl?sid=05/09/23/061 8252 http://it.slashdot.org/article.pl?sid=05/09/23/061 8252 http://it.slashdot.org/article.pl?sid=05/09/16/121 1227 http://it.slashdot.org/article.pl?sid=05/08/21/194 6254 http://it.slashdot.org/article.pl?sid=05/06/10/174 9256 http://developers.slashdot.org/article.pl?sid=05/0 3/11/1359229 http://developers.slashdot.org/article.pl?sid=04/1 2/07/2019244 http://developers.slashdot.org/article.pl?sid=04/0 7/03/1728231 http://it.slashdot.org/article.pl?sid=03/12/31/224 6241

    I am intrigued by your ideas and would like to subscribe to your newsletter.

    --
    <xml><I><am><so><damn>Web 2.0</damn></so></am></I></xml>
    1. Re:No shit? by Karma+Farmer · · Score: 1

      If you want to be interesting or informative, tell us which operating systems don't use MD5.

      Yeah, there are holes in the standard Linux password hashing algo. Wonderful. Great. You're super smart, and get all the girls. Now, tell us something we don't know.

    2. Re:No shit? by ultranova · · Score: 4, Interesting

      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.

      --

      Forget magic. Any technology distinguishable from divine power is insufficiently advanced.

    3. Re:No shit? by Ekarderif · · Score: 1

      OpenBSD. What's that you say? It's considered the most secure operating system? Would Blowfish have anything to do with it?

    4. Re:No shit? by swillden · · Score: 1

      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

      What you say is true, but even if shadow files weren't used, the collision attacks against MD5 wouldn't help an attacker. The reason shadow files are used is to avoid giving the attacker an opportunity to perform a brute force attack, testing lots of candidate passwords, hashing them with the right salt, and seeing if the result matches the user's hashed password.

      What an attacker would really like, ideally, is for MD5 to be broken with a "pre-image" attack, which would provide a way to take the hashed password and "reverse" the hashing process to reveal either the original password, or at least something else that hashes to the same result.

      --
      Note to ACs: I usually delete AC replies without reading them. If you want to talk to me, log in.
  2. Excelent! by EnderWigginsXenocide · · Score: 1, Troll

    This is a great idea. I'll patent it right away.

    --
    Blessed are the pessimists, for they have made backups. -- 0 1 My two bits
  3. MD5 is obsolete. by mellon · · Score: 2, Interesting

    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.

    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. Re:MD5 is obsolete. by mellon · · Score: 1

      Would that it were so. In the open-source world, as with most places, things come in a variety of forms, some of them helpful source code, some of them dense clumps of impenetrable junk source code, some of them in the form of useful advice, some in the form of meaningless drivel. Caveat emptor...

    3. Re:MD5 is obsolete. by Anonymous Coward · · Score: 0

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

      Note that there is now support for other hashes in some form (either patches or built-in) for linux, BSD and solaris. Just as $1$ means "md5", there is $2$ or $2a$ for "blowfish", and a few other less common ones.

      e.g. http://www.linuxfromscratch.org/hints/downloads/fi les/blowfish-passwords.txt ,
      http://web.cps.msu.edu/cgi-bin/man2html?crypt.conf ?4?/usr/man.
      (I think the linux link there is thoroughly obsolete and the functionality has started to appear "upstream", but I can't find the up-to-date reference).

  4. MD5 bashers, RTFA please by MacroRex · · Score: 4, Informative

    The article is not promoting the use of MD5, but rather how external Java apps can directly authenticate against existing crypt() -based hashes.

    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.

    1. Re:MD5 bashers, RTFA please by swillden · · Score: 4, Interesting

      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
      --
      Note to ACs: I usually delete AC replies without reading them. If you want to talk to me, log in.
    2. Re:MD5 bashers, RTFA please by Teogue · · Score: 1

      now THAT sounds cool. Any chance this is open source and published somewhere? I've been wanting to do something like that with our product.

      --
      Quando Omni Flunkus Moritati
    3. Re:MD5 bashers, RTFA please by swillden · · Score: 1

      Nope. It's proprietary closed source. It probably wouldn't be too hard to write a similar PAM module for MUSCLECARD, though... at least for the static password bit. Doing the dynamic passwords might require hacking both the applet (card) code and a RADIUS server.

      --
      Note to ACs: I usually delete AC replies without reading them. If you want to talk to me, log in.
    4. Re:MD5 bashers, RTFA please by Teogue · · Score: 1

      Well, no harm in asking I hope. I just don't have the time or desire to reinvent the wheel.

      Thanks though

      --
      Quando Omni Flunkus Moritati
    5. Re:MD5 bashers, RTFA please by MacroRex · · Score: 1

      Thanks for the clarification.

      Your PAM module sounds very cool indeed, too bad smartcard readers are so rare. I've done some smartcard integration with Java myself, but that was for a specialist environment that had readers in every workstation by spec.

    6. Re:MD5 bashers, RTFA please by swillden · · Score: 1

      Your PAM module sounds very cool indeed, too bad smartcard readers are so rare.

      They're only rare because not many people have been interested in them. The readers cost less than $20 in small quantities and less than $10 in quantities of 1000 or more.

      --
      Note to ACs: I usually delete AC replies without reading them. If you want to talk to me, log in.
  5. Slow news day? by ChrisRijk · · Score: 3, Informative

    The article talks about accessing a particular OS function (local operating system user registry) which requires MD5s. Is that really so interesting that it needs to be posted here? Seems like a lot of people would assume the title suggests all security in Java is based on MD5.

    It's not.

    For example, if you're interested in using AES in Java, here's an article from 2003:
    http://java.sun.com/developer/technicalArticles/Se curity/AES/AES_v1.html

  6. 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.

    1. Re:JAAS? by frodo+from+middle+ea · · Score: 1
      Are you suggesting mapping a Web Application's users to OS users ?

      I can't think of one advantage of doing this and probably a thousand ones to not do so.

      Well may be for a intranet application within the company, but surely not for an internet application.

      On that note , here are 2 main problems I am facing with JAAS authentication that make using JAAS in my Web APP a PITA

      1) Can't pass anything else in login form except username and password. e.g.

      • Create a web login form with username and password.
      • Create a custom login module by extending appropriate base login modules.
      • The web login form has to submit the data to 'j_security_check' The form can be submitted to a Struts Action or another servlet but then the following won't work
        • request.getUserPrincipal() won't return the username, neither will the authenticated prinipal be passed transparently to EJB layer.
        • Single sign-on across multiple web application won't work as that part is usually implemented by j_security_check.
      • Now problem with j_security_check is that when It calls your custom login module it only passes username and password in the Callback Object. So if you need other fields from the login form you are out of luck.
      2) Authentication thru login module is limited to YES or NO. The login module can only indicated whether the user was authenticated or not. But if you have other security policies, such as user must change password on first login, or every 90 days etc, they can't be implemented from the login module. As the login module can't drive which JSP/Action to display next, neither is there a way to set these kind of flags, from the login module that can then be used in the web layer once the user is authenticated.
      --
      for the last time people, I am "frodo from middle eaRTH", not "middle eaST".
    2. Re:JAAS? by icklemichael · · Score: 1

      Are you suggesting mapping a Web Application's users to OS users ?

      No, I'm merely suggesting that if your app server doesn't do it, it is rubbish. Even if it does it may still be rubbish. *cough* websphere *cough* :)

      Well may be for a intranet application within the company, but surely not for an internet application.

      Sadly I just do intranet applications now, being able to integrate with a clients infrastructure with no work is great, excellent ticky box.

      I'm not sure your problems are with JAAS, sounds more like they're with the servlet security gumpth.

      Having said that, we get around your problems with j_security_check by hiding all calls to j_security_check behind a servlet which passes on some requests to j_security_check [1]. It's a bit of a hack but works. There are three real reasons to prefer this over writing your own user stuff:

      • Deployer can set the users up the way they're used to (and so can make it talk to ldap, a database, a flat file, local OS users, etc)
      • Your users are propogated to EJB land auto-magically
      • You can take advantage of the declarative security within your web app

      When I used to write internet apps these reasons were considerably less compelling (where the users lived was always well known - declarative security doesn't give you quite enough control - and well, ejb's, they smell really!)

      [1] Doing this generally, cross app-servers, is a bit of a pain.

  7. 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.

    --
    Xenu loves you!
  8. Check out securityfilter.org by fender_rules · · Score: 1

    It's an open source project which deals with the exact problem you've mentioned above.

  9. Re:JAAS? - Here is a valid use. by Padrino121 · · Score: 1

    From time to time there are valid uses of this type of authentication, I used something similar a few months ago where JAAS can compliment the solution but JAAS itself isn't the solution.

    I had a server on an external DMZ that is back-ended by Windows 2000 AD domain with external user accounts. I also had a requirement to authenticate internal AD users that are only accessible via the external domain and a one way trust. When using LDAP I correctly get a referral to the internal domain however I cannot contact the internal domain myself. I ended up writing a jBoss authentication module and windbind from Samba to make a usable solution.

    The communications path is as follows

    jboss auth-->local PAM-->Windows RPC using winbind to external AD-->windows RPC to internal AD

    This problem had stumped the vendor of the package we are using a number of times, in the end it was Java/PAM to the rescue.

  10. A few things by gd · · Score: 1

    First of all, md5crypt() was invented by Poul Henning-Kemp from FreeBSD project and was released under "THE BEER-WARE LICENSE". Linux distributions adopted it later on.

    Second, MD5 algorithm and md5crypt, while related, are 2 different things. While MD5 algorithm is broken (in academic world, not yet in real usage), I don't think md5crypt is broken. If that is not satisfactory, there is blowfish crypt from OpenBSD project.

    Third, the first Java port of md5crypt I'm aware of was from Ganymede project (http://tools.arlut.utexas.edu/gash2/):

    http://tools.arlut.utexas.edu/cvsweb/cvsweb.cgi/ga nymede/src/md5/MD5Crypt.java?rev=1.12&content-type =text/x-cvsweb-markup

    I was searching for Java port of md5crypt because I was on a project that uses tomcat, which doesn't really provide a satisfactory password hashing algorithm (they only provide MD5 hash). Fortunately, I found Ganymede's port. (Anyone can find a java port of blowfish crypt?)

    Last, I think md5crypt() can be used in any situation where password authentication is required, not only when authenticating against UNIX/Linux system password.

    --
    gd