Win a copy of Mesos in Action this week in the Cloud/Virtualizaton forum!
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

The onsubmit event

 
lekurwale amol
Ranch Hand
Posts: 55
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 13411
Firefox Browser Redhat VI Editor
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Are you doing this instead of using SSL?
If so, why?
 
Bear Bibeault
Author and ninkuma
Marshal
Pie
Posts: 64833
86
IntelliJ IDE Java jQuery Mac Mac OS X
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
author
Rancher
Posts: 15385
6
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 12617
IntelliJ IDE Ruby
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 55
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 15385
6
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 55
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 15385
6
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 55
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 13411
Firefox Browser Redhat VI Editor
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 12617
IntelliJ IDE Ruby
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 13411
Firefox Browser Redhat VI Editor
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 12617
IntelliJ IDE Ruby
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 15385
6
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic