wood burning stoves*
The moose likes HTML, CSS and JavaScript and the fly likes The onsubmit event Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of Android Security Essentials Live Lessons this week in the Android forum!
JavaRanch » Java Forums » Engineering » HTML, CSS and JavaScript
Bookmark "The onsubmit event" Watch "The onsubmit event" New topic
Author

The onsubmit event

lekurwale amol
Ranch Hand

Joined: Apr 22, 2010
Posts: 55
Hi,

I am using RSA algorithm to encrypt password on login page. It will be transmitted to server to be decrypted.
My requirement was to avoid form from storing the text password.
In this context, I need to call the ecryption function before onsubmit. I read somewhere that form data is stored on browser when we submit the form. Can anyone suggest a suitable way (event rather) to call the encryption function, before the browser has started to store form data.

Regards,
Amol Lekurwale
Ben Souther
Sheriff

Joined: Dec 11, 2004
Posts: 13410

Are you doing this instead of using SSL?
If so, why?


Java API J2EE API Servlet Spec JSP Spec How to ask a question... Simple Servlet Examples jsonf
Bear Bibeault
Author and ninkuma
Marshal

Joined: Jan 10, 2002
Posts: 60810
    
  65

It's already been pointed out, and ignored, in other posts on this topic.

And as this has nothing to do with JSP, moved to the HTML/JavaScript forum.


[Asking smart questions] [Bear's FrontMan] [About Bear] [Books by Bear]
Eric Pascarello
author
Rancher

Joined: Nov 08, 2001
Posts: 15376
    
    6
This is funny when I see people wanting to encrypt the password with plain old http requests. They can still grab the encrypted value and use it the same way the plain old text works. It is like locking a door and forgetting to close it.

Browsers normally do not remember password fields unless the user stores the password when their browser asks to remember it. If you get the encrypted value in there, how would you know that from the JavaScript stand point if it is encrypted or not? You probably would end up double encrypting it.

Eric





David Newton
Author
Rancher

Joined: Sep 29, 2008
Posts: 12617

Eric Pascarello wrote:You probably would end up double encrypting it.

Oooo, then it'd be nearly twice as secure!!1!
lekurwale amol
Ranch Hand

Joined: Apr 22, 2010
Posts: 55
Eric Pascarello wrote:This is funny when I see people wanting to encrypt the password with plain old http requests. They can still grab the encrypted value and use it the same way the plain old text works. It is like locking a door and forgetting to close it.

Eric,
I am already using SSL. My issue is not the transportation, but the client. The browser tends to store and so I require a html event, which is fired before onsubmit(after which browser starts storing). In that event handler, I would make the password field blank and send the encrypted through a hidden field.

Browsers normally do not remember password fields unless the user stores the password when their browser asks to remember it. If you get the encrypted value in there, how would you know that from the JavaScript stand point if it is encrypted or not? You probably would end up double encrypting it.

Eric

If browsers did not store, then how can they 'Resend' ? There are specialized tools available, which take the RAM dump. The password is recovered from there. I need to encrypt it.

Regards,
Amol
Eric Pascarello
author
Rancher

Joined: Nov 08, 2001
Posts: 15376
    
    6
lekurwale amol wrote:
If browsers did not store, then how can they 'Resend' ? There are specialized tools available, which take the RAM dump. The password is recovered from there. I need to encrypt it.

Regards,
Amol


What will stop them from taking the encrypted value that is in the RAM Dump? It would still be valid as the plain text.

Have you looked at headers? http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.9.2 You might want to do examine what they have to offer and hope that browsers honor them.

Eric
lekurwale amol
Ranch Hand

Joined: Apr 22, 2010
Posts: 55
Hi,
I already tried with what is said (no-cache, expires etc). But still I have the issue.
From RAM dump, even if you access the password, it would be encrypted and will not be decrypted as it requires a private key which will ofcourse be on the server.

Let us not deviate from the original topic.
Let me know about an event which is fired (all browsers to support) before browser starts caching/storing.

Regards,
Amol

Eric Pascarello
author
Rancher

Joined: Nov 08, 2001
Posts: 15376
    
    6
lekurwale amol wrote:Hi,
I already tried with what is said (no-cache, expires etc). But still I have the issue.
From RAM dump, even if you access the password, it would be encrypted and will not be decrypted as it requires a private key which will ofcourse be on the server.


If the key does not change every time the page is accessed, it does not matter if the password is encrypted or not. The form will be resubmitted with the same info each time. The hacker would not have to know what the original password is at all. They would just need to know the value that is being sent to the server. Any man in the middle attack can get this information.

onsubmit is exactly the point before the form is submitted to the server. You would have to deal with it then.

If you really need your application to be this secure when the form is submitted, I think you are using the wrong technology to do it.

Eric

lekurwale amol
Ranch Hand

Joined: Apr 22, 2010
Posts: 55
Eric,
I would be changing the key everytime. I am now using the following scheme : When user clicks submit, call encryption code, store encrypted password in hidden field ( same for userid). Thereafter clearing the text fields visible to user.
Please comment.

Regards.Amol
Ben Souther
Sheriff

Joined: Dec 11, 2004
Posts: 13410

Maybe I'm lacking imagination but I'm trying to picture the scenario that your anticipating and I'm having a hard time.

The user enters a username and password then submits a form.
At this point that data is somewhere memory space that the browser is running in.

So you're worried that, before the user can close the browser, someone will gain access to their machine, install software to read from the browser's memory, convert the username and password to a human readable form and then do something with it? And you're trying to protect against this with Javascript?

David Newton
Author
Rancher

Joined: Sep 29, 2008
Posts: 12617

Technically the browser wouldn't need to be open still.

None of this would guard against a SW or HW keylogger, and if I can get enough access to pour through the memory of a random program, I'm pretty sure I could get a keylogger in there :D
Ben Souther
Sheriff

Joined: Dec 11, 2004
Posts: 13410

David Newton wrote:Technically the browser wouldn't need to be open still.

True but, once the browser has closed, there is nothing to keep that memory space from being overwritten so the likelihood of someone getting something useful starts to go down with every thing the computer does after the browser has shut down.

David Newton wrote:
None of this would guard against a SW or HW keylogger, and if I can get enough access to pour through the memory of a random program, I'm pretty sure I could get a keylogger in there :D

My thinking exactly.
If the client machine is compromised there is very little that a web app can do to protect the user.

David Newton
Author
Rancher

Joined: Sep 29, 2008
Posts: 12617

Ben Souther wrote:True but, once the browser has closed, there is nothing to keep that memory space from being overwritten so the likelihood of someone getting something useful starts to go down with every thing the computer does after the browser has shut down.

That's why I said "technically" ;) Don't make me come over there and de-cap your RAM and get at old memory values the old-fashioned way!
Eric Pascarello
author
Rancher

Joined: Nov 08, 2001
Posts: 15376
    
    6
lekurwale amol wrote:Eric,
I would be changing the key everytime. I am now using the following scheme : When user clicks submit, call encryption code, store encrypted password in hidden field ( same for userid). Thereafter clearing the text fields visible to user.
Please comment.

Regards.Amol


Instead of storing the encrypted password in the hidden field, how about you just store the encrypted password in the password field?

If you do not want the data to be sent, than get rid of it. lol

Eric
 
 
subject: The onsubmit event
 
Similar Threads
Session in HTTPServlet
In Weblogic, service() being called twice
how to fire two events at the sametime in textbox
how to transfer data from javascript to jsp
Call a javascript function from Java