25

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?

Improve this question
10
  • 2
    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
    Commented Sep 23, 2017 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
    Commented Sep 23, 2017 at 11:59
  • 1
    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
    Commented Sep 23, 2017 at 15:06
  • 7
    @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
    Commented Sep 24, 2017 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/…
    – user144242
    Commented Nov 13, 2017 at 22:14

2 Answers 2

Reset to default
2

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

Improve this answer
-1

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.

Improve this answer
3
  • 6
    Could you give a reason for why this would not be possible?
    – Tom K.
    Commented Nov 6, 2017 at 14:13
  • @TomK. Agreed about the answer, however the whole concept of downvoting in my opinion is a bit harsh
    – Samuel Allan
    Commented Feb 9, 2018 at 23:17
  • 1
    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
    Commented May 24, 2019 at 7:17

You must log in to answer this question.

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