Hacker News Reader

Comment by lima | Hacker News Reader

Not on Windows, but on Linux it's encrypted with your account password (it uses the Gnome Keyring/KDE Wallet APIs).

But none of that is going to help against an attacker with the same permissions.

If that's the case that's a choice Google made. Windows via the CryptProtectData API[0] allows you to protect data via the user's session just like the Gnome Keyring/KDE Wallet.

But as you pointed out, another process with the same privileges can decrypt it making it pretty pointless in both cases. Only way to securely do it is to prompt the user for a decryption key each time they open the browser which has usability issues but Firefox offers it via the Master Password functionality.

[0] https://msdn.microsoft.com/en-us/library/windows/desktop/aa3...

So Windows doesn't have an equivalent of OSX Keychain, where an item can have a per-application ACL? [or I have misunderstood the OSX Keychain]

Correct, Windows does not have per-application identities that could be used with a keychain service. Furthermore, every application in your Windows session (unless sandboxed) has access to virtual memory of other applications in the same session.

On macOS, applications address spaces are isolated and code signing certificates are used for identifying application requests to the keychain.

selinux can help in some of these situations (not saying it will necessarily in this case). Generally speaking, the browser context is not allowed to read user private data like ssh keys. However, since the browser context in this case needs to read passwords, it doesn't apply 1:1. You probably need a different context from the general browser context that can read password data.

Reply on news.ycombinator.com