3 ms·

> Startcom insist that you have your own personal certificate first ... [t]hey could have allowed just a username and password... I assume that this was for TL

> Startcom insist that you have your own personal certificate first ... [t]hey could have allowed just a username and password... I assume that this was for TLS client authentication. Username+password sucks as a method of authentication. The only thing it has going for it is that you can -theoretically- remember your password and key it in on a machine you've never used before. [0] Client certs are effectively unguessable and typically stored in the most secure place that the OS can provide. What's more, there's -IIRC- absolutely no reason for the remote side to remember anything about the certificate that they issued you after they generate it, so there's no risk of a server-side DB breach revealing any significant information about a client's credentials. Frankly, I wish more sites would eschew username/password authentication for username/cert (or at least offer the option of username/cert). Then the UI for certificate operations would certainly get easier to use. :) [0] Though, in today's environment, it seems... highly unlikely that any non-mutant will be able to remember all of the passwords for all of the sites that they use.

rogerbinns 11y ago
Given a clean slate you could possibly make some sort of case for client certificates. But right now username + password is the standard, and people can continue to use whatever solution they deem fit for that. Client certs might in theory be stored in "secure places", but that is not the case in practise. Have anyone get a client cert, and then make a backup or copy to another device. I'll guarantee it is trivially accessible - eg sending it in clear email to yourself to get from one machine to another. It doesn't matter how secure something is, if a standard user would find it highly inconvenient, and it doesn't recognise the modern world of the same user having multiple devices in multiple locations.
- simoncion 11y ago
  > Given a clean slate you could possibly make some sort of case for client certificates. ... It doesn't matter how secure something is, if a standard user would find it highly inconvenient... You obviously missed the point of my comment. I'll highlight the part that most clearly captures the essence of my point: "Frankly, I wish more sites would eschew username/password authentication for username/cert (or at least offer the option of username/cert). Then the UI for certificate operations would certainly get easier to use." > ...and it doesn't recognise the modern world of the same user having multiple devices in multiple locations. Easy fix: issue one cert per device. Does the UI for this suck right now? Yes. Does it have to suck? Fuck no. > Client certs might in theory be stored in "secure places", but that is not the case in practise. It absolutely is the case in practice. Imagine a hypothetical magical computer that stores all username/password pairs in a magical HSM that never lets the username/password outside of the HSM, ever. The credentials in this system are stored in the most secure place that the computer can provide. The fact that the user of that system may have also written those credentials down on a sticky note under his keyboard or saved in a plaintext message in his webmail mailbox does not change that fact. Does that make sense?
  - rogerbinns 11y ago
    I got the point about client certs being more convenient at the point of authentication. My point is that they are considerably less convenient at all other times. How do you get a cert from a Windows machine running IE into an iPhone running Safari? Or vice versa. What about when one of them is off? How do you get a cert onto a device you will use in the future that is in another location under someone else's control. I don't understand how you issue one cert per device. There would be a bootstrap problem, presumably solved by entering a username and password. Or some mythical software/system that is able to securely distribute and update your certs across your systems. Chrome stored my client cert from Startcom in a file in my home directory. Any app running as my user id has access to that file. Since this is a personal workstation, pretty much all the software (some system daemons excluded) runs as me. I don't consider this a secure place in practise, hence the comment. I do agree they could be done differently, but they aren't. Heck I've yet to encounter any browser or similar that uses the TPM in my laptop for security purposes. Client certs seem very similar to ssh keys in usage and needs (secret blobs that need to be backed up and distributed). I know several above average developers who manage theirs well. But then I come across many who don't because it requires too much mental effort. It gets reflected in using passwords for git operations at github. A trivial number of the people who get them right, also don't bother with PGP for email because that is even more painful. For client certs to have any hope of wide usage, the non authentication issues need to be solved, and there is nothing even close.
    - simoncion 11y ago
      > Chrome stored my client cert from Startcom in a file in my home directory. I gather that you don't have a smart card attached to your system? This [0] indicates that Chrome uses Mozilla's NSS to store certificates. The documentation for NSS indicates that it's happy to work with certs stored on (or to store certs on) a smart card. :) Granted, the UI "sucks" for this, but that's part of my point. > I got the point about client certs being more convenient at the point of authentication. That's not what I was saying. Client certs are unguessable, the authenticating partner has no need to store any significant information about the cert, and certs typically rest in the most secure storage the OS can provide. [1] Certs are leaps and bounds safer than passwords. Right now, certs are typically harder to use than than passwords. > For client certs to have any hope of wide usage, the non authentication issues need to be solved... I'm not trying to be confrontational, but didn't you see that this was exactly what I was saying in my previous two comments? No need to write four 'graphs that largely restate what I already said. :) Thing is, if noone uses a thing, the UI for that thing will never get better. You frequently have to offer the thing as an option so that people will start using it before UI design teams will deign to make the UI for that thing better. > A trivial number of the people who get them right, also don't bother with PGP for email because that is even more painful. This is kind of a tangent, but: I guess those people don't use email clients that have adequate support for PGP. Enigmail makes key management, selection, and use trivial. [0] https://chromium.googlesource.com/chromium/src/+/master/docs/linux_cert_management.md https://chromium.googlesource.com/chromium/src/+/master/docs... [1] User mishandling notwithstanding.

rogerbinns 11y ago

Given a clean slate you could possibly make some sort of case for client certificates. But right now username + password is the standard, and people can continue to use whatever solution they deem fit for that. Client certs might in theory be stored in "secure places", but that is not the case in practise. Have anyone get a client cert, and then make a backup or copy to another device. I'll guarantee it is trivially accessible - eg sending it in clear email to yourself to get from one machine to another. It doesn't matter how secure something is, if a standard user would find it highly inconvenient, and it doesn't recognise the modern world of the same user having multiple devices in multiple locations.

simoncion 11y ago
> Given a clean slate you could possibly make some sort of case for client certificates. ... It doesn't matter how secure something is, if a standard user would find it highly inconvenient... You obviously missed the point of my comment. I'll highlight the part that most clearly captures the essence of my point: "Frankly, I wish more sites would eschew username/password authentication for username/cert (or at least offer the option of username/cert). Then the UI for certificate operations would certainly get easier to use." > ...and it doesn't recognise the modern world of the same user having multiple devices in multiple locations. Easy fix: issue one cert per device. Does the UI for this suck right now? Yes. Does it have to suck? Fuck no. > Client certs might in theory be stored in "secure places", but that is not the case in practise. It absolutely is the case in practice. Imagine a hypothetical magical computer that stores all username/password pairs in a magical HSM that never lets the username/password outside of the HSM, ever. The credentials in this system are stored in the most secure place that the computer can provide. The fact that the user of that system may have also written those credentials down on a sticky note under his keyboard or saved in a plaintext message in his webmail mailbox does not change that fact. Does that make sense?
- rogerbinns 11y ago
  I got the point about client certs being more convenient at the point of authentication. My point is that they are considerably less convenient at all other times. How do you get a cert from a Windows machine running IE into an iPhone running Safari? Or vice versa. What about when one of them is off? How do you get a cert onto a device you will use in the future that is in another location under someone else's control. I don't understand how you issue one cert per device. There would be a bootstrap problem, presumably solved by entering a username and password. Or some mythical software/system that is able to securely distribute and update your certs across your systems. Chrome stored my client cert from Startcom in a file in my home directory. Any app running as my user id has access to that file. Since this is a personal workstation, pretty much all the software (some system daemons excluded) runs as me. I don't consider this a secure place in practise, hence the comment. I do agree they could be done differently, but they aren't. Heck I've yet to encounter any browser or similar that uses the TPM in my laptop for security purposes. Client certs seem very similar to ssh keys in usage and needs (secret blobs that need to be backed up and distributed). I know several above average developers who manage theirs well. But then I come across many who don't because it requires too much mental effort. It gets reflected in using passwords for git operations at github. A trivial number of the people who get them right, also don't bother with PGP for email because that is even more painful. For client certs to have any hope of wide usage, the non authentication issues need to be solved, and there is nothing even close.
  - simoncion 11y ago
    > Chrome stored my client cert from Startcom in a file in my home directory. I gather that you don't have a smart card attached to your system? This [0] indicates that Chrome uses Mozilla's NSS to store certificates. The documentation for NSS indicates that it's happy to work with certs stored on (or to store certs on) a smart card. :) Granted, the UI "sucks" for this, but that's part of my point. > I got the point about client certs being more convenient at the point of authentication. That's not what I was saying. Client certs are unguessable, the authenticating partner has no need to store any significant information about the cert, and certs typically rest in the most secure storage the OS can provide. [1] Certs are leaps and bounds safer than passwords. Right now, certs are typically harder to use than than passwords. > For client certs to have any hope of wide usage, the non authentication issues need to be solved... I'm not trying to be confrontational, but didn't you see that this was exactly what I was saying in my previous two comments? No need to write four 'graphs that largely restate what I already said. :) Thing is, if noone uses a thing, the UI for that thing will never get better. You frequently have to offer the thing as an option so that people will start using it before UI design teams will deign to make the UI for that thing better. > A trivial number of the people who get them right, also don't bother with PGP for email because that is even more painful. This is kind of a tangent, but: I guess those people don't use email clients that have adequate support for PGP. Enigmail makes key management, selection, and use trivial. [0] https://chromium.googlesource.com/chromium/src/+/master/docs/linux_cert_management.md https://chromium.googlesource.com/chromium/src/+/master/docs... [1] User mishandling notwithstanding.