1

I am working with JSP.

So when a user submits a form, all the form fields say username and password gets stored in browser memory dump file in clear text.

I even tried with JSP hidden fields, but even that value seems to get stored in clear text.

But if I take dump of gmail login page after a login happens in chrome, only the username gets stored not the password. Though Firefox and IE store both.

Some banking sites, actually change the password altogether say dummy@1234....

May I know how to achieve the same?

Can I change or better remove the password from memory dump.

I tried with individual keystrokes and replace the chars with something else, but in that case I need to still send the actual password to the serever for the authentication purpose.

Please give me some light, in JSP or in JavaScript?

StrugglingCoder
  • 111
  • 2
  • 1
    To be clear: JSP is a Java Server Page and therefore a server-side technology. You ask how you (server-side) can prevent the users browser (client-side) from storing the credentials it sends to you in its own memory/cache/etc.? – GxTruth Jul 18 '18 at 07:00
  • @GxTruth Yes. Can we do it? – StrugglingCoder Jul 18 '18 at 08:14
  • Partialy. See my answer (and goteguru's) and let me know if it answers your question. – GxTruth Jul 18 '18 at 11:35
  • just get rid of the form's password input; no more memory leak. That's why gmail works like that; it doesn't have a pre-filled password box hanging around. – dandavis Jul 18 '18 at 16:28

2 Answers2

1

Your goal is effectively to control browser behaviour and prevent it from storing the password which was entered and sent by the user anywhere (neither cache nor password-storage). As this is client-side software, you generally can't. But we can work out a solution which will achieve what you want in most cases. Please do note that you will never have full control over what the browser stores in RAM, but this is not really a problem. An attacker capable of compromising RAM is also capable of logging keystrokes.

Prevent a submit event from happening

Most browsers notice when you submit a form, because you click a special button (type="submit"). This will probably promt the user "Do you want to store the password for this site?". To prevent this, you can implement this on your own. Don't set type="submit" but create a button <button onclick="performLogin()" that, if clicked, grabs the values of your input fields and wraps them in an HTTP-POST request to your site. If the login is successful, return the session key and write it to a cookie or whatever suits your requirements. Using this approach, you never trigger a real "submit event", but only a click event which won't promt the user for saving the password.

The cache question is trickier and I'm afraid, I don't see a consistent, reliable solution for this one as a browser won't let a random website dictate how it organizes its RAM. However, I can't see a huge drawback when ignoring it. As mentioned above, malicious code capable of reading arbitrary RAM are probably (not always) able to log keystrokes, compromising the password, which is what you are trying to avoid.

P.S.: Always be careful when implementing security measures or authentication mechanis on your own. As goteguru correctly said, "implementing your own security solution may have pitfalls". I'd increase this to "absolutely has pitfalls capable of screwing you over in various ways you never expected, if not handled properly".

GxTruth
  • 963
  • 6
  • 9
  • Thanks for the suggestions. The issue is password gets stored in browsers memory dump file and somehow I have to remove or alternate it altogether. Will the onclick instead of button type submit prevent the values from getting stored at browser's memory dump file? – StrugglingCoder Jul 18 '18 at 12:16
  • What do you refer to as a "memory dump file"? As I said, the RAM management of the browser is outside of your control. Keep in mind that the HTTP request which is generated by a submit-event may also be stored. In addition I can only refer to my answers second-last paragraph. Out of curiosity, what is **so** valueable that you need to clear the password even from the browsers cache? Are you sure it even needs such a high protection? Maybe 2FA is a more secure approach to increase security while avoiding "hacky" implementations. – GxTruth Jul 18 '18 at 12:49
  • attacks exist which won't imply keyboard logging capabilities while still have access to memory dump. One can forensic analyze the swap files or core dumps in mis-configured backups for example. A "may" instead of "is" would be more appropriate. – goteguru Jul 19 '18 at 12:14
  • You got a point there @goteguru. Edited my answer to reflect that the capablity of reading RAM does not imply live keystroke logging. Honestly I did not even think about swap files in misconfirgured backups (good catch). – GxTruth Jul 19 '18 at 13:14
  • @GxTruth Actually I did it once ^-^. However, if the target is using filesystem encryption, and the attacker has physical access, it is possible to power off the machine immediately, and analyze the swap partition for valuable info which is often left unencrypted to support suspend-to-disk (or by ignorance). So there might be "use cases" even without backups involved. – goteguru Jul 19 '18 at 23:21
0

You can build your own input field in js. Capture keystrokes, and fill a dummy input box with asterisks. You can hash the password locally (using a salt provided by the server) and send this hash to the server for checking via your preferred method (hidden field, ajax, websocket).

You can even implement streaming hash, that way the password never will be stored in the memory as a whole ever.

Of course dedicated attacker could reverse engineer your code, but still it would be quite hard to scrape the password from the memory dump.

Word of warning: implementing your own security solution may have pitfalls.

goteguru
  • 643
  • 3
  • 11
  • Thanks for the help. Any suggestion how to even start writing streaming hash? Actually the issue is password gets stored in browsers memory dump file and somehow I have to remove or alternate it altogether. So, I think streaming hash is worth a solution to give a try. Any other simple alternative could be there? – StrugglingCoder Jul 18 '18 at 12:19
  • writing custom hashes may be dangerous unless you are a highly skilled crypto professional. I suggest you to find something reasonable online (even papers are available in the topic). If you want something simple, add every letter to the previous hash and re-hash it. Probably you will have one letter and one hash in the memory all the time. (it depends on the actual string implementation of the processing engine however). (Of course you have to do the same at the server side). – goteguru Jul 18 '18 at 12:56
  • Recommending that a person whom is struggling to something relatively basic instead attempt something very complicated (which, coincidentally, does not fix the problem they are asking about) is not very constructive.And what you propose would make maintaining a secure representation of the password stored on the server much more difficult. – symcbean Jul 19 '18 at 11:19
  • I sincerely disagree. If you think it's not solving the problem, please provide some proof or a hint at least. Writing fold reducer to implement the proposed method is a one liner in most languages, hence I won't consider it complicated, but of course it is a subjective matter. Moreover, I don't think building countermeasures against memory dump attack is "basic", a programmer understanding that would probably be able to comprehend what I suggest. Again, if you think the method wouldn't work, please share your thought. I'm curious. – goteguru Jul 19 '18 at 11:54