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.
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.
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.
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.
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.
iang _______________________________________________ cryptography mailing list cryptography@randombit.net http://lists.randombit.net/mailman/listinfo/cryptography
