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?

Martin Fürholz
  • 795
  • 9
  • 21
  • 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 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
  • 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 Sep 23 '17 at 15:06
  • @Matthew the password is actually sent to the server in clear text. – Martin Fürholz Sep 23 '17 at 19:17
  • 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 Sep 24 '17 at 03:20
  • Have you tried starting with an exact copy of the accounts.google.com page, and making tweaks/changes (binary search) till you can isolate the thing responsible for this behaviour? – ShreevatsaR Oct 10 '17 at 22:23
  • Google Chrome stores the login credentials of user for various websites as under an SQLite db "Login Data " in this location "..Chrome\User Data\Default" and it's really OS dependent how these credentials are protected. Sometimes passwords are triple DES encrypted. – Soufiane Tahiri Nov 03 '17 at 10:48
  • 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. - https://www.owasp.org/index.php/OWASP_Application_Security_FAQ#Is_it_really_required_to_redirect_the_user_to_a_new_page_after_login.3F – Joshua Gimer Nov 13 '17 at 22:14
  • Can the bellow help you? source: https://stackoverflow.com/questions/32369/disable-browser-save-password-functionality/37292424#37292424 – Hugo Dec 22 '17 at 15:10
  • Chrome seems to treat some Google websites with favouritism. That might be the reason. – wizzwizz4 Dec 31 '17 at 10:46

2 Answers2

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

Samuel Allan
  • 132
  • 8
-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.

forest
  • 64,616
  • 20
  • 206
  • 257
jtillman
  • 127
  • 3
  • 6
    Could you give a reason for why this would not be possible? – Tom K. Nov 06 '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 09 '18 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 May 24 '19 at 07:17