Details

Description

Class org.mortbay.jetty.security.Credential provides the possibility to verify against a stored MD5 hash as well as providing one from a password given. Plain password hashes are vulnerable to rainbow table attacks when the password file is leaking (which could be the case when using HashUserRealm, which stores the hashes in a plain file). Therefore a salt is added to each password before being hashed to avoid this kind of attack. It would be worthwile to consider adding such a functionality to org.mortbay.jetty.security.Credential and org.mortbay.jetty.security.Credential.MD5.

I am relating to version 6.1.24 I am currently using. I scanned the bug database not finding the issue, therefore I assume that it is present in all versions.

Greg Wilkins
added a comment - 27/Sep/10 2:26 AM Richard,
Does the salt need to be protected? Would it be sufficient to have a setSalt method on the realm and related credential methods?
If the configuration file that contains the salt is compromised at the same time as the stored MD5 hashes, is there any additional protection?
Sorry if this is a dumb question, but I don't want to appear to be adding extra security unless I get it 100% correct.

Anyways, from my knowledge,the salt should not be per realm but rather per user. Therefore as a first step I would recommend the possibility to add a salt provider to the realm. Whenever the hash is calculated the salt provider is asked for the salt (returning a byte array), with the user name as parameter. Implementations would than have the possibility to inject the salt stored along with the user. The default implementation may store the user specific salt along with the hashed password, making the leaked hashes more secure against rainbow table attacks http://en.wikipedia.org/wiki/Rainbow_tables. Even though the salt is leaked with the hash in that case, it requires computing a rainbow table for each user which then is effectively the same as a brute force attack (rainbow tables for plain passwords can be downloaded from the internet), making the attack infeasible for strong passwords.

While we are at it : MD5 has severe vulnerabilities, see http://en.wikipedia.org/wiki/MD5#Security, you might consider offering AES support as well or open up the Credential class in a way that a client may choose his favourite hashing algorithm (this would also enable support for the currently planned successor of AES). But this may be worth a separate bug report.

Richard Birenheide
added a comment - 27/Sep/10 2:58 AM - edited Greg,
please refer to http://en.wikipedia.org/wiki/Salting_(cryptography) , I am afraid that I cannot account as deep expert, to be honest.
Anyways, from my knowledge,the salt should not be per realm but rather per user. Therefore as a first step I would recommend the possibility to add a salt provider to the realm. Whenever the hash is calculated the salt provider is asked for the salt (returning a byte array), with the user name as parameter. Implementations would than have the possibility to inject the salt stored along with the user. The default implementation may store the user specific salt along with the hashed password, making the leaked hashes more secure against rainbow table attacks http://en.wikipedia.org/wiki/Rainbow_tables . Even though the salt is leaked with the hash in that case, it requires computing a rainbow table for each user which then is effectively the same as a brute force attack (rainbow tables for plain passwords can be downloaded from the internet), making the attack infeasible for strong passwords.
While we are at it : MD5 has severe vulnerabilities, see http://en.wikipedia.org/wiki/MD5#Security , you might consider offering AES support as well or open up the Credential class in a way that a client may choose his favourite hashing algorithm (this would also enable support for the currently planned successor of AES). But this may be worth a separate bug report.
Regards
Richard
Edit: Also a great read on the topic: http://chargen.matasano.com/chargen/2007/9/7/enough-with-the-rainbow-tables-what-you-need-to-know-about-s.html

Jari Timonen
added a comment - 27/Nov/11 2:37 AM Salt is a must with hashed password. Otherwise MD5 passwords are extremely insecure. Current functionality is unusable. (JDBCLoginModule is also unusable)
Please?