Re: password changes
Brought to you by:
xystrus
From: Derek M. <co...@pi...> - 2006-01-30 10:58:37
|
On Mon, Jan 30, 2006 at 09:25:08AM +0000, Tim Cutts wrote: > > I think it is you who does not understand. If your environment really > > warrants the paranoia, this can be worked around. You can have them > > upload their key (both halves) to a secure bastion server, stored in > > their home directory WHICH THEY DON'T OWN AND CAN'T WRITE TO, and > > forced to log into the network from that system. > > Isn't that just moving the problem? How do you then authenticate > them on the bastion server? Yes, IN PART, it absolutely is -- if the system where the user types their password/passphrase is compromised. I already explained that in a previous message. But what you have gained by going to all this trouble is that you have guaranteed that the connection into your network is encrypted AND that the person using the keys on the system must use the correct passphrase for the key associated with the account they are using. That is the whole point, and that is the best you can ever hope to do with SSH, unless you are willing to go to more sophisticated technologies... Since our bastion host gives us that guarantee, whatever method of authentication you use to protect it is really academic. You could use none at all, and it would be NEARLY as good as any other method you chose. The only difference is it would give any idiot with an ssh client free reign to attempt to brute-force all your users' passhphrases. If you REALLY require this level of security, the best way to authenticate them on the bastion server is probably to use some kind of security fob, like smartcard. Configure the bastion host with only the minimum software required to run ssh (no compilers, no user tools of any kind beyond what the system needs to boot and to run SSH), don't put any host or password information on the bastion that would reveal anything about the rest of your network. As I mentioned before, the users should not own any files and should not be able to write anywhere on the filesystem. These measures limit your exposure if someone gains unauthorized access to the bastion. But unless they've obtained someone's passphrase, even a root compromise of the bastion would not allow them entry into your network, because that access would require a successful SSH connection from the bastion to an internal machine, using ssh keys which you know for certain contain passphrases. But if you REALLY require this level of security, you have to start with your users. You have to be able to trust them. Before you can trust them, you have to educate them so they understand the risks, and the consequences. If you REALLY require this level of security, and you can not do those things, then you are fighting a losing battle. Your users can and will defeat you every time (intentionally or not), if they can not be made to cooperate. In the end, every method of authentication can be defeated. If the user's system (or for that matter, the users themselves) are compromised, neither keys nor passwords can be trusted. It's that simple. But since keys provide better protection from attackers gaining access via other means besides compromising the user's system, they are better, and should always be preferred to passwords. > Besides, at the end of the day, the degree of paranoia is a decision > for the system administrator and the organisation's policy-makers. Definitely. > That's why I would argue that the facility to be able to change a > password should be a feature which can be optionally compiled into > rssh, rather than needing an extra patch - the decision whether or > not to enable it is ultimately the installing site's responsibility. I feel like a broken record. To summarize: This functionality is intented to compensate for careless users who use keys with no passphrases. This is the *only* remotely viable reason to use passwords over keys. However switching to passwords is a reactionary measure and a specious solution; in cases where the users are so careless, using passwords makes zero practical difference compared to just using keys, which generally are better than passwords for many reasons. The only way an attacker could compromise the user's key -- even if it had no passphrase -- is to gain possession of it. This can only be done if the system on which the key resides is somehow compromised, in which case passwords can just as easily be obtained in a variety of ways. This has been demonstrated in my previous posts. As such, there is no compelling reason to ever use passwords. This functionality can not be well integrated into rssh (any solution involving chroot jails is at best a half-solution). This functionality is a bad solution to the wrong problem. This functionality will not be included in rssh. If you still think that the functionality should be included, it is because you believe that I am wrong to think that passwords can not help you solve this problem. That is not a question of deciding what degree of paranoia to accept -- it is an assesment of what the degree of paranoia actually is. I believe I have logically demonstrated conclusively that keys are normally superior, and in the worst case no worse than passwords. You can disagree, but since it's my software, I win that argument by default. ;-) I am not so stubborn that I could not be swayed by a compelling logical argument, but in several years of trying, no one has yet presented one, as far as I'm concerned. And I don't think anyone ever will. You're free to keep trying. But for the moment I'm sick of going in circles with this issue, so I'm going to ignore any further posts on this thread. I've already spent way too much of my time on it, and I should have been in bed hours ago... Have a nice day. ;-) -- Derek D. Martin http://www.pizzashack.org/ GPG Key ID: 0x81CFE75D |