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.
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.
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.
It's weird that we cook bacon and bake cookies. Eat this tiny ad:
Two software engineers solve most of the world's problems in one K&R sized bookhttps://coderanch.com/wiki/718759/books/Building-World-Backyard-Paul-Wheaton