On 10/11/2015 17:58, Michael Orlitzky wrote: > On 11/10/2015 10:30 AM, Alan McKinnon wrote: >>> Maybe, but your argument isn't convincing. How am I better off doing it >>> your way (what is your way)? >> >> The most common way is to disallow all remote logins as root. Admins log >> in with their personal unpriv account using an ssh key. To become root >> they must su or sudo -i with a password. >> >> Benefits: two factor auth using different mechanisms. Having the key or >> the password is not enough to become root, an attacker must have both. >> >> Allowing root logins directly over the network is considered bad >> practice, due to the "one mistake = you lose" aspect. >> > > It sounds good, but what sort of attack on my root password does the > two-factor authentication prevent? Assume that I'm not an idiot and to > brute-force my root password would take literally forever. > > I'm weighing this against the complexity of adding separate accounts, > making sure that *those* are secure, risking breakage of the sudoers > file, granting someone the ability to brute force my SSH key password > offline,... > > All of the good attacks (shoot me, bribe me, steal the hardware, etc.) > that I can think of work just fine against the two-factor auth. The only > other way to get the root password is to be there when I transfer it > from my brain to the terminal, in which case you have the SSH key, too.
I think you are approaching this problem from the wrong viewpoint. You have to assume an attacker has vastly more resources to bear on the problem than you have. Thanks to Amazon and the cloud, this is now a very true reality. Brute force attacking a root password is nowhere near as complex as the maths would lead you to believe; for one thing they are decidedly not random. The fact is that they are heavily biased, mostly due to 1) you need to be able to remember it and 2) you need to be able to type it. Humans have been proven to be very bad at coming up with passwords that are truly good[1] and hard for computers to figure out. And our brains and very very VERY good at convincing us that our latest dumb idea is awesome. Are you really going to protect the mother lode (root password) with a single system proven to be quite broken and deeply flawed by wetware? Two factor auth is cheap (ssh-keygen and ssh-copy-id) and keys take the human factor out of the first step. It's not security theatre nor cargo culting, so why not use it and gain the benefits for minimal effort? Complexity of separate accounts is a bit of a red herring. If your user account is weak, I have to assume so is your root account - apart from UID=0 there is no difference between them. Hopefully you use Puppet or friends so you set up a decent template once and the system ensures it stays that way. No having to check if user accounts really are still not weak. Finally the root password by it's nature is a shared secret between one or more admins. On every system a boss has had me look after, I have shown to my own satisfaction that it is the weak link. It has to exist, it has to be known an it has to be communicated when it changes. Systems designed to help make that process safe are themselves weak (such as a GPG encrypted file protected by .... a never-changing shared password that every admin knows!) Am I going to build a front line of defence based on ssh keys? You betcha. Alan [1] Our bosses and auditors keep coming up with stupid ideas designed to improve this but all they succeed in doing is causing the problem they seek to solve. Such as rotating passwords, insisting on punctuation, no repeating characters. In the real world all this does is invite *bad* practices - people have to resort to this to get something that satisfies the password policy and they can remember. And from there it's a short step to Post-It-Note syndrome -- Alan McKinnon alan.mckin...@gmail.com
