I think most linux distro's protection of certificate private keys is pretty weak (just storing a .pem file somewhere) and I can't say anything about OSX but on Windows you can prevent the private key from being disclosed even if the user wants to export it and enforce entering a password or PIN each time the certificate is used. Getting access to the physical hardware is about the only way to bypass the CryptoAPI, which is pretty far from 'any' client compromise.
You can't actually "prevent the private key from being disclosed even if the user wants to export it" out of box on Windows [if you have an HSM this may be an option although it may also make the keys unsuitable for some purposes]. You can make it _annoying_ which is a stock in trade for Microsoft designs, but attackers don't care about it being annoying. The reason is that the CryptoAPI hands over the keys to an application for it to use (it does not function only as a proxy like say ssh-agent), and so application can export the keys. People even make ready-to-use apps to do this, because, as described above, the CryptoAPI behaviour is annoying.
You can require a password, but that's true for text files on a Linux system too. So why don't most people use a secret password to protect a file with a secret key inside it? Because it's yet more pointless busy work, again a stock in trade of Microsoft environments.
Also, because this is so very annoying you don't need physical access but only console access, which you can of course get remotely, as otherwise administrators of the mountains of Windows servers set up this way couldn't type in all the passwords needed over RDP every day. (If you're lucky they are using an encrypted RDP session to do this...)
> You can't actually "prevent the private key from being disclosed even if the user wants to export it" out of box on Windows [if you have an HSM this may be an option although it may also make the keys unsuitable for some purposes].
All modern laptops ship with TPM that basically allows provisioning private keys in an non exportable way. Additionally server can remotely attest that the key is stored in the TPM. (your HSM remark probably covers this though)
I agree that CryptoAPI is nasty, but if your key doesn't have the CRYPT_EXPORTABLE flag set when it was created then it can not be exported by CryptoAPI, and can only be accessed maliciously by breaking the CryptoAPI (by patching it in memory, which requires full admin access to a running system) or accessing the OS disk offline.
CryptoAPI does not hand over the key and delegate signing and encryption to the application. Instead, it provides APIs for signing and encryption and does not disclose the private key.
> CryptoAPI does not hand over the key and delegate signing and encryption to the application. Instead, it provides APIs for signing and encryption and does not disclose the private key.
There is no proxy, they keys live in your process. Because Windows is proprietary they can do the moral equivalent of:
If you did this in OpenSSH, everybody would laugh because they could see it in the source code. "This doesn't make the key unexportable Beavis, you idiot". But in Windows they can solemnly announce that the key isn't exportable and as you've demonstrated, people believe them even though some introspection tells us this can't be true (Where is the key? Like, really, where - it isn't in a proxy because there isn't one... when we load it _our_ process gets bigger and in a debugger we can see it's in our memory, just CryptoAPI tells us we're not supposed to export it...)
You don't need to patch anything the keys are stored in %APPDATA%\Microsoft\Crypto\Keys for user certs, they are "encrypted" if the protection flag is set but there are plenty of tools to recover the key material from those files, the protection material is stored in %AppData%\Roaming\Microsoft\Protect :)
OpenId, OAuth, et al are similar to Kerberos: Using a central authentication server to issue tokens that are trusted for authentication to a third party. OAuth seems a little bit weaker compared to Kerberos since there is no mutual authentication, instead we tend to rely on HTTPS for this.
Last time I checked we had TLS Client Certificates and TLS Certificate Pinning. So yes, we do have mutual auth. Additionally, OAuth2 is not an authentication flow.
> Additionally, OAuth2 is not an authentication flow.
I've heard this before, but tbh I'm not familiar enough with auth systems to see why it's true. I've certainly used "login with Facebook", etc. as an alternative to email/password login for sites I've created in the past, and I've seen others do so.
