Secured MD5/Encrypted form based login for JBoss portal

Question

I have currently created a form based login for JBoss portal server and my login page looks like (served on HTTPS only):

<form action="j_security_check" method="post">
     Enter UserName: <input name="j_username" type="text" />

     Enter Password: <input name="j_password" type="password" />

     <input type="submit" value="Submit" /> <input type="reset" value="Reset" />
     </form>

During security testing of application, it was recommended to not send the password in plain text and instead have some MD5 or other encryption, so that no one can extract the password on intercepting the request.

How can I implement this in JBoss portal form based login?

Answer 1

You've gotten some bad advice here.

Best standard practice is to send the password itself to the server, provided the link is SSL/TLS protected. Your application should receive that password, hash it (not using MD5 but a legitimate salted hash (or bcrypt, which is the best solution there)) and then compare it to the stored salted hash. Therefore, your application never stores user passwords, so if your password file/database got compromised, noone's password would be exposed and, if you use a strong salted hash/bcrypt algorithm noone should be able to brute force the hash to recover the actual password.

However, you need to do this on the SERVER side, within your application. Your application should take the password and do this hashing. If you hash the password on the client and send the actual salted hash to the application, you're opening yourself up to a different attack. If someone did steal your password file/database, they would know the hash of a user's password. If you have the client send the hash to the server, an attacker would then know exactly what hash to send and could access any user's account! Instead you want the client to send the password itself and have the server generate the hash based on it, so the attacker would not know what to send in an attempt to log in as a user (since you cannot take a salted hash and recover the password from it, assuming a strong salted hash implementation).