4 ms·

The problem that exists with TLS certs, and not with PAKE, is usability. Client certs suffer from questions like "as a user, how do I handle multiple devices?

• amelius 8y ago
  Yes, see "PGP" for an example where good crypto tech fails when the UX is not on par.
• parliament32 8y ago
  To be fair the UX for client side certs is pretty idiotproof once you have the cert installed. You get a "X site is requesting an identity certificate" box. Installing certs is pretty painless too -- you navigate to a certain page and get a "this site is attempting to install a security identification certificate in your browser" box. Securely getting to that page is a different matter. As for logging in on untrusted devices (biz center, friend's PC, etc)... you shouldn't be doing that under any circumstances in a high security situation.
  • dogma1138 8y ago
    The problem with certificates is that A) it requires the user to install them on every device B) they are required to be installed on every device C) they are a bitch to manage and distribute and D) protection around certificates is fairly weak and any client compromise will lead to the exposure of all credentials. You also end up delegating the authentication to your transport layer which is never that good of an idea.
    • elblanko 8y ago
      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.
      • tialaramex 8y ago
        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...)
        • Boulth 8y ago
          > 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)
        • elblanko 8y ago
          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.
• derefr 8y ago
  > Client certs suffer from questions like "as a user, how do I handle multiple devices? Logging in from my phone? Logging in from the biz center at some hotel / my friend's phone / etc? I see this as a perfect case for "logging into your browser" (Chrome Sync/Firefox Sync/iCloud Safari Keychain sync/etc.) Why not have any issued client certs be global to your "browser account" rather than local to your device? The cert bundles can also be transferred and stored using end-to-end encryption (like iMessage keybags.) Sure, now you can't tell which of a person's devices they're on from just the cert you're seeing. That's what cookies or localStorage would be for, since they explicitly don't sync between devices. Client cert for AAA + session cookie for holding the server-side connection ID.