Eric Pascarello wrote:You probably would end up double encrypting it.
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.
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
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
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.
David Newton wrote:Technically the browser wouldn't need to be open still.
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
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.
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
Don't get me started about those stupid light bulbs. |