3

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

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. – user2300868 Apr 25 '16 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. – user2300868 Apr 25 '16 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 '16 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. – user2300868 Apr 25 '16 at 19:56
  • The salt isn't a secret. It could be totally public without any issues. – Daisetsu Apr 25 '16 at 20:12

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.