Question

I have a form on my .jsp page which sends a password back to the server.

<form name="login" action="j_security_check" method="post">
    <input type="text" name="j_username">
    <input type="password" name="j_password">
    <input type="submit" name="Login"> </form>

I would like to do some processing on the j_password before processing it.
Previously, I managed to do this by implementing a JavaScript through some processing codes by calling on a function that performs something similar to below:

<script type="text/javascript" src="sha256.js">
<script> function hash() { document.login.j_password.value = '@' +
    sha256_digest(document.login.j_password.value); } </script>
...
...
    <input type="submit" value="Login" onClick="hash()"> </form>

Now, I am trying to implement a similar feature but instead of using JavaScript, I am trying to use Java. The main aim of my .java is to load a public.key, take the j_password, perform encryption, and replacing the j_password with its encrypted form.

// RSA.java Pseudocode
1) Get string from textbox "j_password"
2) Load public key from public.key
3) Perform encryption on j_password with key
4) Load cipher to textbox "j_password"

However, most examples I see implement a “<% %>” calling but this gives me an impression that it would perform on page load, rather than on clicking the login button. I also noticed I could compile it as a .class with javac and load it as an “” but can this method be used to modify the input of j_password? While it is a .jsp and I can implement Java directly with “<% %>”, I don’t think it is acceptable in current JSP standards. Does anyone have any recommendations or ideas to point me in the right direction?

Thank you.

Answer 1

You can use Filters for encryption, but it won’t be on the client side. As you can see in that list, filters are used for Encryption too, like you need for your purpose. The only way to intervene something is through the use of Filters. But if you need client side encryption, only way out is JavaScript.

Further you can have a look at this and this.

The second link provides a good explanation for hashing the password on client side. One of the answers mentions this :

For this matter, more secure authentication protocols usually jump through a number of hoops in order to make sure, that such a replay attack cannot work, usually, by allowing the client to select a bunch of random bits, which are hashed along with the password, and also submitted in the clear to the server.

On the server:

• generate a few bits of random
• send these bits (in clear text) to the client

On the client:

• generate a few random bits
• concatenate password, the server’s random bits and the client random
  bits
• generate hash of the above
• submit random data (in clear text) and hash to the server

As the server knows its own random information as well as the client’s random bits (it got them as clear text), it can perform essentially the same transformation. This protocol makes sure, that nobody listening in this conversation can use the information later to authenticate falsely using the information recorded (unless a very weak algorithm was used…), as long as both parties generate different “noise bits” each time, the hand shake is performed.