Secure Java Apps on Linux using MD5 Crypt 25
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).'"
No shit? (Score:1, Insightful)
Re:No shit? (Score:2)
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:1)
Re:No shit? (Score:5, 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.
Re:No shit? (Score:2)
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
Excelent! (Score:2, Troll)
MD5 is obsolete. (Score:3, Interesting)
Re:MD5 is obsolete. (Score:3, Insightful)
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."
Re:MD5 is obsolete. (Score:2)
MD5 bashers, RTFA please (Score:5, 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.
Re:MD5 bashers, RTFA please (Score:5, 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.
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:
Re:MD5 bashers, RTFA please (Score:1)
Re:MD5 bashers, RTFA please (Score:2)
Re:MD5 bashers, RTFA please (Score:1)
Thanks though
Re:MD5 bashers, RTFA please (Score:2)
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.
Re:MD5 bashers, RTFA please (Score:2)
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)
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/S
JAAS? (Score:4, Insightful)
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.
Re:JAAS? (Score:2)
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.
Check out securityfilter.org (Score:1)
Re:JAAS? (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, s
Re:JAAS? - Here is a valid use. (Score:2)
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)
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.
A few things (Score:1)
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]