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
    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
    Sep 4, 2021 at 0:10
  • I reformatted the question to make it easier to identify footnotes
    – schroeder
    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
    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
    Sep 30, 2022 at 0:51

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

  • 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
    Sep 4, 2021 at 11:50

You must log in to answer this question.

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