On 03/02/2011 02:36 PM, Charles Morris wrote: > > e.g. Turn off authentication on your in.telnetd, post your IP on FD, > and tell me how that works out for you.
Any sensible person turned off telnetd long ago. When it existed with password authentication, password capturing was rampant. Even worse, these captured passwords usually granted access to other systems. So, yes, telnet with plaintext password authentication can be worse than telnet without it. "How much worse" is inversely proportional to the value of the system running the telnetd. Even challenge-response authentication schemes are often not immune to various forwarding attacks. On 03/02/2011 03:38 PM, Tim wrote: > Ok great, but by comparing MitM with sniffing, we're already > assuming the attacker has access to the traffic. Think about it. > There aren't any networks in common use today which in their physical > implementation make alteration of packets harder than observation of > packets. This is why the big-Os are the same. Well, there are some network links on which it's easier to observe traffic than inject it, e.g., unencrypted satellite downlinks. But these networks are that way by accident, not because of any requirement that they guarantee this as a security property. And most application traffic may just as easily be routed over other other networks in the future. Strong data integrity is simply not something a software developer can expect out of the network. It's exactly why we need IPsec and SSL/TLS. > On Mar 2, 2011, at 12:36 PM, Charles Morris wrote: > > It is. A parachute that works a nonzero % of the time (encryption > without authentication) is infinitely better than one that you can > BE SURE WILL NEVER WORK (plaintext) I would argue it is much much worse. All unreliable parachutes must be systematically destroyed. You should ask some actual professional parachuters how they feel about the idea of keeping half-busted parachutes lying around. > The application, or parachute, should warn of the danger involved > so the user may make an educated choice. As a software developer I too feel the desire some times to simply push off the difficult questions on to the user. E.g.: "The certificate is incorrect. Your connection may have been redirected to a malicious server or proxy conducting a man-in-the-middle attack. Would you like to connect anyway? Click 'OK' to fail (i.e., get pwned), or click 'Cancel' to not succeed." If the developer doesn't know if something is secure, how likely is it that the user will be able to intelligently evaluate the risks? This is not even a statistical "risk" like, say, an earthquake. It's fundamentally at the option of the attacker whether or not the user is under an active attack at any given time. If the user were able to know whether or not they were under active attack at any given time, they wouldn't need the security software, would they? Therefore, expecting the user to evaluate such a risk is equivalent to the software not providing security. I.e., it's broken. On 03/02/2011 05:42 PM, bk wrote: > > I really, really hate liars, and people who pawn off encryption > (that amounts to really expensive encoding) without authentication > as "security" are evil. Don't fucking lie, just tell the users > they're going to be compromised if they use your stuff, so they know > better. People are being tortured and killed because their connection to Facebook is not secure. This shit is real. - Marsh _______________________________________________ Full-Disclosure - We believe in it. Charter: http://lists.grok.org.uk/full-disclosure-charter.html Hosted and sponsored by Secunia - http://secunia.com/
