Is it possible to protect browser credentials from malicious processes?
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.
