I did some testing, and found that a memory dump of Chrome doesn't hold the password of gmail.com/Google after logging in to that site (the login happens on accounts.google.com).

(My System is Windows 10 64bit Professional, Chrome 60).

I can find the passwords of all other sites I've tested. Also when I do the same in Firefox, the gmail.com password will be stored in the memory dump. This is a Chrome-specific behaviour.

I've tried a lot of things to prevent the password from being stored in a memory-dump. Even when I hash the password in the password-field before submitting the form, the original (un-hashed) password will be contained in the memory dump. I tried with autocomplete="off", I tried sending the password through a 'hidden' field, and an invisible text field. (So that the browser won't attempt to store the password in the built-in password-manager).

I've also - of course - tried with deactivated password-storage, cleared the cache, experimented with Cache-Control/Pragma/Expires -headers, and what not. And I know that the Gmail-website does indeed send the unhashed/original password in the request to the server. So there is no client-side method involved to encrypt/hash/obfuscate the password.

So my question is: whatever gmail.com (accounts.google.com) uses so that the password is not contained in a memory dump, would it be possible to do the same for my own website? Or is that possibly a hardcoded, gmail.com-specific feature of the Chrome-browser?

Could it be coincidence, because that site causes a lot of read-/write-activity on the memory, so that the Garbage Collector cleans up faster, or something like that?

  • 1
    If your attacker had the ability to memory dump a process, you already have lost the battle. Chrome likely doesn't store passwords in memory because, unlike Firefox, Chrome doesn't actually have a built in password manager. Instead Chrome uses the system's password manager/keyring. Though against an attacker that can dump memory, obfuscating memory are just smoke and mirrors, and does not provide real security against determined attackers. Your much better off investing your time on securing aspects that are actually defensible. – Lie Ryan Sep 23 '17 at 10:21
  • 1
    @LieRyan you misread my text, and even the headline. Chrome does store passwords in memory. Just on this particular Google website (accounts.google.com) it doesn't. And I'm interested in learning how this is possible. – Martin Fürholz Sep 23 '17 at 11:59
  • Are you signed into Chrome with the specific Google account you're using? If so, it's entirely possible that there is some other form of token being used to maintain access, which would explain the difference between Firefox and Chrome too – Matthew Sep 23 '17 at 15:06
  • 6
    @LieRyan I can definitely think of a scenario of social engineering, where some 'tech support' would ask someone to send in a memory-dump (which only takes a few simple steps). So I think that this is a valid concern. – Martin Fürholz Sep 24 '17 at 3:20
  • 4
    Your browser will also cache POST requests that is receives a 200 level response for. This may be contributing to the problem. You need to issue a 300 level response for POST requests containing sensitive information. This instructs your browser to not store the request in memory for later submission. - owasp.org/index.php/… – Joshua Gimer Nov 13 '17 at 22:14

From what I can guess you really only have two options here:

Option 1 : Work from Google

Start by very closely observing Javascript/network behaviour. As somebody mentioned in the comments, working from a total clone could yield good results. However, personally I really would not look forward to doing that kind of hardcore debugging.

Option 2 : Some javascript that (could) help

Anything but sending the password in the POST. For example here are all valid (untested) solutions:

  • Try replacing every character as it is typed (for instance encrypting the orginal key with a stream cipher with a session-specific key - then it can be recovered on the other side)
  • Try simply capturing key input and simulating it appearing into the textbox (that way nothing at all gets cached - I doubt keystrokes are cached :D )
  • No guarantee this will work: but try just manipulating the input contents right before post (but do keep in mind that something simple like a Ceaser Shift really will not work, because a smart enough attacker WILL just reverse that)

I have a strong suspicion the 2nd approach in the above list is the only thing that will work (capturing key input), because it is likely the inputs on the textboxes are still kept in memory (I have no idea how Google handles this - but I have strong faith in the 2nd option on the list).

Perhaps later today/tomorrow I will post a minimal example with tests


No it’s not possible. Unless you want to build your own browser and encrypt the browser dump or create a service agnostic token auth client.

  • 3
    Could you give a reason for why this would not be possible? – Tom K. Nov 6 '17 at 14:13
  • @TomK. Agreed about the answer, however the whole concept of downvoting in my opinion is a bit harsh – Samuel Allan Feb 9 '18 at 23:17
  • The answer is wrong. Question was about "how" is that behaviour done in Chrome. You can't say it is impossible to modify if you don't know / can't explain how it is done currently. – Marki555 May 24 at 7:17

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.