How to encrypt passwords using j_security_check?

[richardberger]

Building a system where users can self register. Thought it would be nice to encrypt their passwords. Can use Sun's JCE to handle the encryption. But how to make this work with j_security_check? Is this finally a reason to drop j_security_check and do everything in JAAS?

Has anyone tried to do this? Any feedback would be appreciated - it seems like a common task.

Thanks all!
RB

[richardberger]

I haven't implemented it yet, but this actually appears straightforward.

1. On the form, change the name of the password field from "j_password" to "raw_password".
2. Create a hidden field named "j_password"
3. Prior to the form being submitted, calculate the MD5 digest for the password - since we are just verifying the password upon login, we can use a one-way encryption. MD5 javascript algorithms are available on the web.
4. When the user registers, use the same MD5 javascript to "encrypt" the password they entered.

(As I started writing this, I thought I needed to use MD5 that is part of JDK, but it is even easier).

Will repost once it all works.

RB

[richardberger]

Turns out that this is indeed trivial and can all be done in JavaScript. Basically I just had a "j_password_raw" field where the user entered text and before calling j_security_check, I encrypted the password with a one-way has h and put the result in the "real" j_password field. No need for JCE or even anything on the server.

Of course, this isn't really secure since I am not using SSL, but it does solve the problem of having passwords in cleartext in the database.

Enjoy,
RB

[kenryu]

hi;
Do you mind post the complete code on the forum? Thank's before I appreciate it.

[noel.rocher]

Hi Richard,


Why doing that hashing in the navigator when you can do it with java on the server ?
You still need a ssl protection, so for simplicity, the only field you need in your form is the password.
I've done it and save the digest in a user table for further authentication (in a very simple application).
It works fine.

Noel

[kenryu]

hi Noel;
can you send me the sample code please? Thank's before I appreciate it.


^_^

[kenryu]

hi Noel;
can you send me the sample code please? Thank's before I appreciate it.


^_^

[noel.rocher]

Hi kenryu,

Here is the code :
=========================================
MessageDigest encryptor = MessageDigest.getInstance(ENCRYPT_ALGORITHM);
encryptor.update(myPasswordString.getBytes());
myDBStorage.setPassword(java.net.URLEncoder.encode(new String( encryptor.digest()) ) );
=========================================

Note that I use URLEncoder class to obtain readable/db-storable string (without any strange char that can cause problems) and this class changes in the JDK1.4. Read the javadocs that will tell you all about this change.

ENCRYPT_ALGORITHM is a string constant that can take some values as "MD5" "SHA" ... (again more on the javadocs).


Pleased to help you.

[richardberger]

Sorry - was on vacation - but it looks like your question has been solved. Apologies for any inconvenience - let me know if I can be of any future help.

RB

[kenryu]

actually you can probably help me with sending me a sample code...:)


Thank's

[ronaldtm]

Then there's no security at all! If someone listen to the connecion and get the parameters, he could use the already encrypted password to replay the login. The TCP connection itself isnt encrypted (as using SSL), and the password is still in plain text (although hashed by MD5).

There must be a way to make the connection though SSL...

[ronaldtm]

The previous was about the MD5 at the client. About hashing the password in the server, it protects the password from the database administrator, because he wont see it in plain text, but wont prevent from anyone that captures the connection to read the password in plain text.

Again, we need SSL, although I dont know how exactly to do it... Maybe with the parameter CONFIDENTIAL at the descriptor?

[richardberger]

Ronald: You are absolutely correct. This does nothing to prevent snoopers. It only provides security from someone browsing through the database - they won't be able to see the passwords there.

For over the wire security, SSL is needed and I think that CONFIDENTIAL is the way to go, but since I haven't configured SSL, I can't be absolutely sure.

My system is a "fun system" but I wanted to be able to tell users that I wouldn't be able to read the passwords that they entered - not that this was a secure system.

Enjoy,
RB