My situation:

  1. Login password from a POST request is left in browser memory in clear text as long as cache is not cleared (manually/closing browser).

  2. Connection is HTTPS.

Possible Solution:

  1. Generate public-key and private-key on server for each login request.
  2. Send public-key to browser.
  3. Use JavaScript to encrypt the password with the public-key and send to server.
  4. Decrypt using the private-key and validate.
  5. Delete keys after login.

My question is, is this feasible? Pros and Cons? Are there any security vs. performance considerations?

I've gone over a few questions like:

  1. Hashing client side
  2. Webcrypto
  3. javascript crypto

The first one doesn't really answer my question as I'm suggesting generating a new pair of keys on every request (which honestly is my biggest worry as far as feasibility and performance). The other two links seem to suggest that javascript crypto is basically pointless as long as you have an HTTPS connection. Thoughts?

1 Answer 1


Generating another public-private key would be overkill for this senario.

If you're really worried about some malware reading the browser cache, you can instruct the browser to just not cache anything.

<meta http-equiv=”Cache-Control” content=”no-cache” />
<meta http-equiv=”Cache-Control” content=”no-store” />

If you're worried about someone reading through the memory to find the plaintext of the username and/or password then you can implement at a solution similar to the one defined in senario #2 here (http://resources.infosecinstitute.com/browser-based-vulnerabilities-in-web-applications/)

Note that you have to scroll down a bit on that page to see the content, there's a giant ad that pops up first.

  • Ah I've seen that suggestion else where..and it would be quite a bit less work than implementing different public keys on every request.
    – Silom
    Apr 25, 2016 at 13:50
  • But is this possible to implement with a password that's already hash and salted in db? I might be missing something here.
    – Silom
    Apr 25, 2016 at 14:28
  • If you are salting on the client side and the server that become a bit more complicated. You would have to salt, then hash in the client side, then do that operation again on the server side. The difficulty is letting the client side know what salt to use.
    – Daisetsu
    Apr 25, 2016 at 18:22
  • No, what I mean is hashing and salting the password in storage so I would have to send the user's static salt to the client as well as the random salt. Which would make it less secure.
    – Silom
    Apr 25, 2016 at 19:56
  • The salt isn't a secret. It could be totally public without any issues.
    – Daisetsu
    Apr 25, 2016 at 20:12

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .