0

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.

Em Cee
  • 107
  • 3
  • 11
  • 1
    Just a thought: One encrypts password because you don't want raw password to be passed to the server over a network. If you are encrypting the password on server side, then it defies the purpose. – Subir Kumar Sao May 14 '12 at 07:49
  • Yes, hence I am wondering if there is a way to do this encryption before submission on the client side, but using Java to do it. – Em Cee May 14 '12 at 07:55
  • 1
    In a typical Java web application anything you write on Java gets executed on server side. So javascript is your only option. – Subir Kumar Sao May 14 '12 at 07:57
  • Oh damn, I guess I'll have to dig deeper for an alternative. Though I had the impression that Java applets can run client side with JVM. – Em Cee May 14 '12 at 08:01
  • You might want to upvote helpful answers and accept an answer that was more likely the solution that you wanted. – Kazekage Gaara May 14 '12 at 13:56
  • Although I didn't manage to get an applet running on clientside with JVM, I realised I could just attach the modulus and exponent on hidden fields when loading JSP, to use a RSA.js to do the encryption. – Em Cee May 15 '12 at 08:16

2 Answers2

0

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.

Community
  • 1
  • 1
Kazekage Gaara
  • 14,972
  • 14
  • 61
  • 108
  • Hi. I have already implemented the Filter for server side. It will decrypt the password using the private key. – Em Cee May 14 '12 at 07:53
  • Well, Encryption on client side has only one option then, JavaScript. Otherwise you will have only one way to intervene before your password reaches the server, that is using a Filter(again, it wouldn't occur on client side, it'll be on server side). – Kazekage Gaara May 14 '12 at 08:00
0

Are you trying to encrypt a password for submission to the server? If so you can't use JSP as the processing is performed on the server, not the client.

JSPs are a method of building dynamic web pages using Java, but all processing directives are translated onto servlets where they then follow a regular servlet lifecycle. If you want to encrypt on the client, you need to use a client side language. Bear in mind, that if you delivering / receiving your submission using SSL the data load will automatically be encrypted.

If you're converting for storage into a DB then you are as well off using a standard servlet for your form handler.

codeghost
  • 1,014
  • 7
  • 14
  • Hi. Yes, I am intending to encrypt on the client side, submit to the server, a filter will decrypt the password for j_security_check. I know it is client side, and I am supposed to use a .js. Unfortunately, I have not found a javascript file that encrypts using RSA2048 with my designated public.key. – Em Cee May 14 '12 at 07:54
  • 1
    http://www.jcryption.org/ will allow you to encrypt on the client side. Be warned though, this is still a flawed approach as you are still exposed to man in the middle attacks and provide no trust mechanism. You really should be using SSL. – codeghost May 14 '12 at 08:00
  • Thanks. I will look into jcryption. Yeah, SSL is enabled but I am looking to see what-if scenarios where SSL isn't. – Em Cee May 14 '12 at 08:05
  • You control whether SSL is used or not, it's not an optional extra to the end user, so there really should be no situation in which this would be an issue. Regarding applets this is executed client side, but you're now requiring your users to have Java installed and enabled. It is a far heavier approach. – codeghost May 14 '12 at 08:09