On 1/3/2012 4:21 PM, Les Mikesell wrote: > On Tue, Jan 3, 2012 at 5:12 PM, Bennett Haselton<bennett at peacefire.org> wrote: >>> The critical thing to remember is that in key auth the authenticating key never leaves the client system, rather an encrypted 'nonce' is sent (the nonce is encrypted by the authenticating key), which only the server, possessing the matching key to the authenticating key, can successfully decrypt. >> Actually, the top answer at that link appears to say that the server >> sends the nonce to the client, and only the client can successfully >> decrypt it. (Is that what you meant?) >>> This effectively gives full bit-strength for the whole key; 1024 bits of entropy, if you will, for 1024 bit keys. This would appear to require a 157 character random password chosen from all 95 ASCII printable characters to match, in terms of bit entropy. >> Yes, I've acknowledged that whether you think 1024 bits is more secure >> than 72 bits depends on how literally you mean "more secure". If the >> odds of an attack working in the next year are 1 in 10^10, you can >> reduce the odds to 1 in 10^20, which in a strict mathematical sense may >> make you more secure, but -- not really. > You are still speculating about the wrong things, though. Is your > password written down? Has anyone ever been in the same room when you > typed it? Could a key logger have been installed anywhere you typed > it? Right, but these are all valid concerns if you use keys as well. If someone's in the room when you type in the passphrase for your key, they might come back in later and take the key and use the passphrase. If they install malware, they can capture the passphrase and the key as well. > And for the brute-force side of things, these may be done from > a large number of sources to a large number of targets. They may be > too slow to break any specific target but repeat it enough and you'll > match something, somewhere. Well yes but that doesn't make *my* password any less secure if it's chosen from a space of 10^21 possible passwords. The attacker will just move on. > Maybe you were just the lucky one that > day - and if you used the same password on the other(s) they would be > easy targets. > >> However, *then* you have to take into account the fact that, similarly, >> the odds of a given machine being compromised by a man-in-the-middle >> attack combined with cryptanalysis of the stream cipher, is *also* >> overwhelmed by the probability of a break-in via an exploit in the >> software it's running. I mean, do you think I'm incorrect about that? >> Of the compromised machines on the Internet, what proportion do you >> think were hacked via MITM-and-advanced-crypto, compared to exploits in >> the services? > Proportions don't matter. Unless you have something extremely > valuable to make this machine a target or someone captured your > password and connection destination it was probably a random hit of a > random probe. It doesn't matter if they are likely to work or not, > some do. I either disagree or I'm not sure what you're saying. What do you mean that "proportions don't matter"? If attack A is 1,000 times more likely to work than attack B, you don't think it's more important to guard against attack A? Wasn't that exactly what you were advising when you said to worry more about someone capturing my password with a keylogger, than brute-forcing it? >> The problem with such "basic stuff" is that in any field, if there's no >> way to directly test whether something has the desired effect or not, it >> can become part of accepted "common sense" even if it's ineffective. > If you have multiple layers of protection and look at your logs, > you'll see what people are trying. And they keep trying it because it > works... Well they might be "trying" it because it works against some other systems (in particular, brute-forcing a weak password). That doesn't mean it's any more likely to work on a system with a 12-char random password. > If you aren't looking at your logs there's not much use in > speculating about what might be happening. > > >> Case in point: in the *entire history of the Internet*, do you think >> there's been a single attack that worked because squid was allowed to >> listen on a non-standard port, that would have been blocked if squid had >> been forced to listen on a standard port? > Generalize that question to 'do you think attacks are helped by > permitting applications to use ports the administrator didn't expect > them to use' and the answer is clearly yes. There are certainly rogue > trojans around that do who-knows-what on other connections while > pretending to be your normal applications. Well that seems like it would be trivial for the trojan to circumvent -- just listen on the standard port, and if you receive a connection that contains the "secret handshake", switch that connection over into trojan mode, while continuing to serve other users' standard requests on the same port. Wouldn't that work? In that case it seems like a case of a restriction that might work until it becomes widely deployed enough for trojan authors to take it into account, at which point it becomes obsolete. Bennett