Is it possible to protect browser credentials from malicious processes?

Question

What items should be considered to create a browser that prevents all access to stored credentials by a malicious process? Hardware attacks being out of scope.

Are there public projects addressing this?

In an attempt to answer this myself, I've looked around a little bit. At the time of writing, and to my understanding, this goal is impossible to reach with existing tools. Below is my current understanding.

---

All the literature I can find on MDN, Chrome Dev Blog, Chromium Security, and elsewhere seems to assume a trusted execution environment¹. Any malware that can access browser system files can compromise user credentials before they expire, if they expire. eg: with Chrome you just have to wait for the sqlite db containing cookies to hit the disk and scrape everything off it.

Naively, if one were to require the user to authenticate on every interaction, that could work, however that would be bad UX. An alternative would be to have the credentials stored in a location that is inaccessible to any process and to any identity² other than the one which has been authorized to use them.

That would imply some OS/Kernel level facilities to enforce process+identity authentication, and in the context of a web browser, per-origin³ isolation and denying any cross-origin access as well. The latter may be possible using an incantation of HSTS, CORS, XFO, COEP, COOP, CSP, CORP, and CORB.

For the former, to my knowledge, there's no secure storage type of registry in either Linux or Windows. It might be achievable using a hypothetical browser that is identity-aware that would create a user per identity+origin, restrict all OS-level objects of that identity+origin combo to only that user, spawn at least one process using the dedicated user. That way, only malware with superuser access would be able to perform unauthorized actions, but that's not enough for the original use case. I can think of additional requirements to achieve credentials protection, even against superuser malware:

• Per identity+origin drivers and io: even with a hypothetical secure storage, if a superuser can update drivers, it can install keyloggers, highjack input and redirect output to capture any and all the information in those processes.
• Hardware storage of credentials: The only surface of attack in the OS/kernel should be the process authentication, no other systems should be exploitable to capture credentials. (Eg: Storing root/key-encryption keys in a TPM)
• There are very likely other requirements.

¹ Let me know if this is wrong, I'm not sure if the Web Authentication API fits that category as this document lists it as vulnerable, (Page 22) https://icmconference.org/wp-content/uploads/A33a-Corella.pdf

² Businesses using platforms like Azure often require multiple accounts per employee to mitigate some security risks. Any isolation for those platforms would have to not only be per-origin, but per-account as well to prevent a compromised non-administrative account to exploit a vulnerability in the browser or program to get a hold of credentials of other identities stored for that same origin.

³ To prevent the usual web attacks.

Answer 1

I think you have answered your own question. You have laid out the problem and highlighted the issue that processes run as a user gets access to whatever the user does. So, everything stored within the browser for the user is accessible to the user of the browser.

To mitigate that, you would need to set up a 3rd party system to gate access, but that system would also need to be accessed by the user, so you would need to add a layer to mitigate that. And that new layer would be accessible by the user ... and so on and so on in a never-ending cycle of data access processes trying to protect themselves from each other while permitting consistent access under the user's context. All the while trying to solve the problem of determining who is actually authorised to access the data with no means of doing that (you, yourself, are very "hand-wavy" on that point).

It's like creating a safe with a thousand nested safes, but they all have the same combination. The thousandth safe is "super protected" but not functionally more protected than the first.

In terms of effective leverage to protect the stored data within an application, trying to protect the application and the user from themselves is highly inefficient. And ultimately prone to complete failure.

The far more efficient approach is to prevent the malicious process from running or detecting the malicious process when it does run. It's not perfect, but it can be effective in a large set of cases.