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 environment1. 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 identity2 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-origin3 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.

1 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

2 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.

3 To prevent the usual web attacks.

  • 1
    You are asking many questions within a single post. I'd suggest you to split them into separate posts. 1) About protecting browser data. 2) About credentials for Azure. 3) About attacks: Here define what attacks exactly you mean, because "usual web attacks" is way too generic and such question will be closed.
    – mentallurg
    Commented Sep 4, 2021 at 0:04
  • Let me clarify, my question really is about 1. I mention azure only as an example, and ask nothing (I think) about 3. To me this really is only one question about how to protect information of web apps. (Edit) numbers 1,2,3 are footnotes, apologies for the formatting
    – gxtaillon
    Commented Sep 4, 2021 at 0:10
  • I reformatted the question to make it easier to identify footnotes
    – schroeder
    Commented Sep 4, 2021 at 7:45
  • It took me a while to understand what you were actually asking. You used very general and high-level language and repeated yourself. I tried to make sense of the question by using more specific terms and making the question more concise. Has my edit been in line with your intent?
    – schroeder
    Commented Sep 4, 2021 at 7:57
  • Concerning malware escaping the browser context (as that was one of your subquestions), QubesOS may be an option to look into. It's bulky and overkill for many cases but isolates all applications into containers, minimizing attack surface.
    – belkarx
    Commented Sep 30, 2022 at 0:51

2 Answers 2


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.

  • I get what you are saying, but after having slept on it, now I don't think it has to be this way. The problem is context isolation and the combination of permitted unless denied, and superuser is what prevent the web from being safe. There's no reason anyone else, including the superuser, should be able to read or modify user data. The only thing that's really needed is denying logon and deleting a user, if drivers are all in userland, this way the worst that can happen is a denial of service.
    – gxtaillon
    Commented Sep 4, 2021 at 11:50

In general, no. Not only do you have to worry about attacks on the data storage (from privileged users or other processes running under the same user as the browser, never mind hardware), you also have to worry about attacks on the browser itself. The simplest one would be to start the browser in a debugger, or use debug APIs (ReadProcessMemory/ptrace) on the browser (either having started it as a child process, or having sufficient privileges to attach anyhow, which often just means "running as the same user"). Since the browser obviously must have access to the credentials, the attacker would be able to read them directly out of the browser's address space. Protections against the browser being debugged would mitigate this, if the attacker lacks sufficient privileges to attack directly via the kernel.

It might be possible to construct a "security module" using hardware-supported process isolation (or actually separate hardware, such as a TPM) to store the credentials. In that case, the browser would not in fact ever see the credentials; it would simply format a request with placeholders for them, submit the request to the security module, and the security module would populate the placeholders and then send the request. Obviously though, there's a lot of limitations here:

  1. The security module needs to know what credentials go with what destinations, and update them as needed.
  2. The security module needs sufficient storage for all the credentials (and their metadata, such as origin and expiry and so on), and this storage of course must not be attacker-readable.
  3. The security module needs to be able to send network traffic without it passing back to normal processes.
  4. The security module needs to be able to intercept and strip credentials (e.g. cookies containing tokens) back out of the response; this gets especially hard when you have servers returning credentials in e.g. arbitrary JSON structures.
  5. The browser can no longer inspect credentials in any way before sending (e.g. to see if they have certain claims, etc.) unless the security module is very clever about stripping only the right parts.

In practice, malicious code running with user (or higher) privileges is generally "game over" for security of that user's data, including credentials.

You must log in to answer this question.

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