On 30 May 2012 05:01, ianG <i...@iang.org> wrote: > On 29/05/12 11:03 AM, Peter Maxwell wrote: > >> >> >> On 29 May 2012 01:35, Peter Gutmann <pgut...@cs.auckland.ac.nz >> <mailto:pgut...@cs.auckland.ac.nz>> wrote: >> >> Peter Maxwell <pe...@allicient.co.uk <mailto:pe...@allicient.co.uk>> >> >> writes: >> >> >Why on earth would you need to spread your private-key across any >> number of >> >less secure machines? >> >> The technical details are long and tedious (a pile of machines that >> need to >> talk via SSH because telnet and FTP were turned off/firewalled years >> ago, I >> won't bore you with the details). The important point isn't the >> technical >> details but the magical thinking, "a private key sprayed all over >> the place in >> plaintext is more secure than a line-noise password because everyone >> knows >> passwords are insecure and PKCs are secure" (and, as I've said, this >> isn't an >> isolated case). >> >> >> >> To make an analogy: people still manage to kill themselves in cars >> fitted with seat-belts and airbags. That does not imply those measures >> are not an improvement but rather that the improvement is a statistical >> one. >> > > > Right! And that has to be measured rather than speculated about.
Fair enough. Out of interest: how many systems have you known to be compromised via ssh public key auth? Now, how many systems have you seen compromised through bad password handling? > > > Similarly, just because some numpty stores private keys in plaintext >> does not imply that public key auth is not in general an improvement >> over password auth. Yes, it is not magical but if the users of such >> systems cannot handle private keys with at least minimal care, there are >> bigger problems afoot. >> > > > The false presumption in this argument is that users can handle anything > with some assumed level of minimal care. > > The goal is to find something that works best with the users' limited > attention and knowledge. Passwords 'work' because at least the users know > them, sort of. Although PK is a theoretical improvement over passwords in > all technical senses, that is only a theoretical analysis and does not > necessarily translate to user context. Especially, if the imposition of > PKs requires the user to 'protect' the private key, all the technical > presumptions drift rather rapidly from reality. The particular result of > this is that SSH's limitations forces a lot of unencrypted private keys, as > does SSL/HTTPS for server keys. > > No, I deliberately did not make such an assumption. My argument was one of like-for-like comparison: if users cannot handle private keys with minimal care then they also cannot handle passwords with minimal care and neither method wins, although arguably public key auth still has advantages. That users know passwords and they "work" is a large part of the problem with passwords: the same low entropy security token is used for multiple systems with varying levels of sensitivity. When using passwords, both the user and the end systems must, in general, be trusted with the security token; so say a user uses the same password on 20 services then *all* of those services must be secure *and* the user must keep the password secure. For public key auth, only the user must keep the private key secure, the other systems do not require trust. > > If multiple users need to use SSH on multiple hosts, they should store >> the private key on removable media and use it from a limited number of >> hosts; to "hop" from one host to another, create a port-forward on the >> first ssh session form which the second ssh session can connect through >> to the destination host, hence obviating the requirement for copying >> private keys and ensuring the intermediate hosts cannot decrypt any >> traffic. >> > > > Would be nice. When it's up and going, installed, on common platforms, > and available easily for users, that will be useful. It is not difficult, sshd does port-forwarding in the default configuration. All that is required is the user knowing to port-forward through the intermediate host instead of copying their private key to it, which is a basic standard management/user education problem. And before anyone suggests this is impossible or difficult, I have seen a similar system with several thousand users and hundreds of hosts without people leaving their private keys all over the shop. The policy is easy enough to enforce, if a private key is found where it shouldn't be then the users' public keys are removed from all hosts and they are required to create new keys and start again. This stuff isn't magic, its basic security management. > > > I have yet to encounter a problem in real life that requires private ssh >> keys to be copied all over the shop >> > > > I've seen it. Last week: E.g., repositories run by difficult sysadms > that don't respond. They add one ssh key to the repository. To get > access, the next programmer is tempted to borrow the ssh key of someone > else. > > Call these people bad, if you like. I call them productive programmers. I call that poor management, whether the programmers in question are productive or not. There is no *requirement* for private ssh keys to be stored on more than one host in your scenario, that's just people choosing not to do it. > > > and when it happens, it's bad >> management, which no technical measure is going to sort. >> > > > Right, that last part - anything that requires the users to engage in > 'management' which technical measures can't cope with ... is a losing game. Au contraire, the thing that organisations with good security records all have in common is good management. There's many an organisation with good technical security but without decent security process and they tend to fail badly.
_______________________________________________ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
