[Distilling to the core matter; everything else is peripheral.] On Jan 4, 2012, at 2:58 PM, Bennett Haselton wrote: > To be absolutely clear: Do you, personally, believe there is more > than a > 1 in a million chance that the attacker who got into my machine, got > it > by brute-forcing the password? As opposed to, say, using an > underground > exploit? Here's how I see it breaking down: 1.) Attacker uses apache remote exploit (or other means) to obtain your /etc/shadow file (not a remote shell, just GET the file without that fact being logged); 2.) Attacker runs cloud-based (and/or CUDA accelerated) brute-forcer on 10,000,000 machines against your /etc/shadow file without your knowledge; 3.) Some time passes; 4.) Attacker obtains your password using distributed brute forcing of the hash in the window of time prior to you resetting it; 5.) Attacker logs in since you allow password login. You're pwned by a non-login brute-force attack. In contrast, with ssh keys and no password logins allowed: 1.) Attacker obtains /etc/shadow and cracks your password after some time; 2.) Attacker additionally obtains /root/.ssh/* 3.) Attacker now has your public key. Good for them; public keys don't have to be kept secure since it is vastly more difficult to reverse known plaintext, known ciphertext, and the public key into a working private key than it is to brute-force the /etc/shadow hash (part of the difficulty is getting all three required components to successfully reverse your private key; the other part boils down to factoring and hash brute-forcing); 4.) Attacker also has root's public and private keys, if there is a pair in root's ~/.ssh, which may or may not help them. If there's a passphrase on the private key, it's quite difficult to obtain that from the key; 5.) Attacker can't leverage either your public key or root's key pair (or the machine key; even if they can leverage that to do MitM (which they can and likely will) that doesn't help them obtain your private key for authentication; 6.) Attacker still can't get in because you don't allow password login, even though attacker has root's password. This only requires an apache httpd exploit that allows reading of any file; no files have to be modified and no shells have to be acquired through any exploits. Those make it faster, for sure; but even then the attacker is going to acquire your /etc/shadow as one of the first things they do; the next thing they're going to do is install a rootkit with a backdoor password. Brute-forcing by hash-cracking, not by attempting to login over ssh, is what I'm talking about. This is what I mean when I say 'multilayer metasploit-driven attacks.' The weakest link is the security of /etc/shadow on the server for password auth (unless you use a different auth method on your server, like LDAP or other, but that just adds a layer, making the attacker work harder to get that all-import password). Key based auth is superior, since the attacker reading any file on your server cannot compromise the security. Kerberos is better still. Now, the weakest link for key auth is the private key itself. But it's better protected than any password is (if someone can swipe your private key off of your workstation you have bigger problems, and they will have your /etc/shadow for your workstation, and probably a backdoor.....). The passphrase is also better protected than the typical MD5 hash password, too. It is the consensus of the security community that key-based authentication with strong private key passphrases is better than any password-only authentication, and that consensus is based on facts derived from evidence of actual break-ins. While login-based brute- forcing of a password that is long-enough (based upon sshd/login/ hashing speed) is impractical for passwords of sufficient strength, login-based brute forcing is not the 'state of the art' in brute- forcing of passwords. Key-based auth with a passphrase is still not the ultimate, but it is better than only a password, regardless of the strength of that password. If your password was brute-forced, it really doesn't matter how the attacker did it; you're pwned either way. It is a safe assumption that there are httpd exploits in the wild, that are not known by the apache project, that specifically attempt to grab /etc/shadow and send to the attacker. It's also a safe assumption that the attacker will have sufficient horsepower to crack your password from /etc/shadow in a 'reasonable' timeframe for an MD5 hash. So you don't allow password authentication and you're not vulnerable to a remote /etc/shadow brute-forcing attack regardless of how much horsepower the attacker can throw your way, and regardless of how the attacker got your /etc/shadow (you could even post it publicly and it wouldn't help them any!).