ssh and security [LWN.net]

ssh and security

Posted Dec 5, 2003 18:24 UTC (Fri) by giraffedata (subscriber, #1954)
Parent article: ssh and security

OK, but lets cut to the chase on what change the letter proposes: It does not propose a challenge-response system, because SSH already has that. It proposes to move authentication out to an isolated, hardened system.

The paper with the passwords on it is such a system. It can't do a fraction of what a Linux system can do, and so is much harder to compromise. The smartcard has similar properties. Because it doesn't have the flexibility to do things like run a web server, it's much harder for someone to break into it and steal your keys than it is to break into a Linux system and steal its SSH keys.

(Log in to post comments)

ssh and security

Posted Dec 6, 2003 4:20 UTC (Sat) by dlang (subscriber, #313) [Link]

I am warning that the strength of the authentication that ssh provides is only as good as the security on the remote machine. if it's a strongly protected machine you can say with a fair amount of confidence that the ssh connection really is from the user that you say that it is, if the remote machine is something you have no idea what it's configuration is then you really don't know if the ssh connection comeing from it is really the person it says it is.

as a result the ssh user authentication is not good enough for the use that it is routinly put to.

I'm not saying that both sides of the authentication need to be seperate from ssh, but I am saying that the client side needs to be seperate so that a remote comprimise doesn't grant access.

there was a story a year or so ago about someone who was putting keystroke sniffers on the public access machines at kinkos. this would mean that anyone who used ssh from those machines becomes a direct threat to the servers that they log into.

for opensource project servers with hundreds or thousands of users can you really trust that there isn't SOMEONE in this group that uses ssh from a insecure machine? as soon as someone does then that account could become a stepping stone for an exploit like Debian suffered where a local exploit is essentially the same as a remote exploit.

You are right about the core being the need to move authentication out from the general purpose system, but there is the additional layer of trying to shock people out of their complacency and the growing mindset that ssh == secure

in addition there is a slight hope that if enough people find the argument reasonable that openssh can pickup a modification that will allow this to take place easily ;-)

PDAs and ssh and security

Posted Dec 11, 2003 23:02 UTC (Thu) by eli (subscriber, #11265) [Link]

As an admittedly partial step in the direction you describe in your letter, you might
consider that many developers have PDAs that could be used in the
challenge-response process. Have a key on the pda and generate the response
from it (and maybe the time). (I'm envisioning the pda displaying it for the user to
enter.)

I store my passwords on my PDA (encrypted with a master password), so this would
be the next logical step. I'd feel a whole lot better with a setup like that for my home
PCs.

Thoughts?

PDAs and ssh and security

Posted Dec 12, 2003 22:47 UTC (Fri) by dlang (subscriber, #313) [Link]

a PDA does a good job of this and can replace a hardware token.

ASSUMING that the contents of the PDA are secured appropriatly.

for example if the application checks your password and then if it matches gives you access to a datafile someone else can get access to the data if you sync it to your desktop.

however if the data on the PDA is encrypted with no encryption key ever stored on the PDA then it's much better

for example if you need to store a 64 bit key on the PDA the best way I've seen is to ask the user for a PIN and then encrypt the key useing that PIN and store the result, when the user needs to access the key have them enter a PIN and use that to decrypt the key, the thing that makes this work is that the key is a random binary blob, an attacker has no way of knowing if it decrypted sucessfully or not, the only way to know is to attempt to use it to access another system. this means that even with a 4 digit PIN it will take an average of 500 login attempts to find that it's right, giveing you a chance to notice (to many bad login protection)