The onsubmit event

[lekurwale amol]

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]

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

[Bear Bibeault]

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.

[Eric Pascarello]

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]

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

Oooo, then it'd be nearly twice as secure!!1!

[lekurwale amol]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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