Slashdot is powered by your submissions, so send in your scoop

 


Forgot your password?
Close
typodupeerror
×
Security

Secure Java Apps on Linux using MD5 Crypt 25

Posted by ScuttleMonkey 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).'"
This discussion has been archived. No new comments can be posted.

Secure Java Apps on Linux using MD5 Crypt More

Secure Java Apps on Linux using MD5 Crypt

Comments Filter:
    • 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.

    • Re:No shit? (Score:5, Interesting)

      by ultranova ( 717540 ) on Tuesday January 17, 2006 @04:16AM (#14488992)

      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.

      • 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 pa

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

  • MD5 is obsolete. (Score:3, Interesting)

    by mellon ( 7048 ) * on Tuesday January 17, 2006 @02:45AM (#14488742) Homepage
    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.
    • 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."
      • 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...

  • MD5 bashers, RTFA please (Score:5, Informative)

    by MacroRex ( 548024 ) on Tuesday January 17, 2006 @02:46AM (#14488747)

    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.

    • Re:MD5 bashers, RTFA please (Score:5, Interesting)

      by swillden ( 191260 ) <shawn-ds@willden.org> on Tuesday January 17, 2006 @09:26AM (#14490035) Journal

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

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

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

  • Slow news day? (Score:4, Informative)

    by ChrisRijk ( 1818 ) on Tuesday January 17, 2006 @02:52AM (#14488764)
    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 [sun.com]

  • JAAS? (Score:4, Insightful)

    by icklemichael ( 521080 ) on Tuesday January 17, 2006 @04:18AM (#14488998)
    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/ [sun.com]

    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.
    • 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.
      • Crea
      • It's an open source project which deals with the exact problem you've mentioned above.

      • 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, s

    • 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 conta

  • SRP is the right approach to passwords (Score:4, Insightful)

    by Paul Crowley ( 837 ) on Tuesday January 17, 2006 @11:51AM (#14491216) Homepage Journal
    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 [stanford.edu], 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.
  • 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://t [utexas.edu]

Slashdot Top Deals

Top Ten Things Overheard At The ANSI C Draft Committee Meetings: (10) Sorry, but that's too useful.

Close