Cart
|
[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] Re: Re: Cookies at XML Europe 2004 -- Call forParticipation
 At 10:28 PM -0500 1/7/04, Rich Salz wrote: >> I'm understanding this attack correctly, using state would only >> remove the need to verify after the initial, verified transaction. >> Can the attacker not send just as many initial, malformed requests? >> How does maintaining state present this attack? > >It narrows down where you have to do DoS But it still allows it. Using session keys instead of state narrows the hole through which the DOS attack can pass. However, it doesn't close it, and since the hole is in a predictable place, the attacker can still walk right through it. If there is a real problem with DOS attacks based on malformed encrypted messages, using session keys doesn't fix it. :-( >> I see you're thinking here more about the DOS than key theft. For key >> theft, the good guys and the bad guys do not benefit equally from >> increased efficiencies. > >Not at all. If I get a more powerful processor, I can use a bigger >nonce in my digest-auth. If the adversary gets a more powerful >processor, he can do more dictionary, password-guessing, attacks. No, the situation is not symmetric. Doubling the nonce (or the key length) would double the work the encrypter (good guy) has to do. It would more than double the work the attacker has to do to decrypt the message without knowing the key. >But it's not really DoS, but DDoS, a zillion zombie machines. >That's because the workload is equally divided between client and >server -- sending the bad packets is as costly as receiving them >in a SYN flood, e.g. In a crypto DOS attack, it's one machine, one >bad message, and I've doubled the load on your server. The asymmetry >of creating bogus crypto versus detecting it is inherent. It's much easier to defend against a non-distributed DOS than a distributed DOS. And systems do defend themselves against even DDOS attacks today using routers. Defending against a crypto-based DOS would not be harder. And one machine, one packet will not double the load on my server (unless it's a very lightly used server that only gets one packet in normal usage.) It will double the load per request, a very different thing. Many servers have cycles to spare. This would need to be a DDOS to have a real impact. A problem? Yes. A crippling, insurmountable problem much worse than the status quo? No. >> Anything like this should be done with SSL. > >SSL isn't appropriate. SSL provides data privacy *while the data >is in transit.* It does not provide any offline validation, >authentication, or privacy. There is a real important reason why >the IETF renamed it TLS. It's transport security, not application >data security. SSL is hop-by-hop, not end-to-end. Yes, the remote site can still be hacked and your credit card numbers and other sensitive data be stolen. This is a much bigger problem in practice than packet sniffing to steal individual passwords or session keys. The ends are insecure. However, cookies don't solve this problem either. My point is that while it may not be theoretically ideal to send the encrypted password over SSL (TLS) in every connection instead of just the first, it's not a practical problem either. SSL effectively prevents both dictionary attacks on digest authenticated keys and replay attacks on session keys. Without SSL, there's no protection for cookies from replay attacks and some protection for digest authenticated passwords. -- Elliotte Rusty Harold elharo@m... Effective XML (Addison-Wesley, 2003) http://www.cafeconleche.org/books/effectivexml http://www.amazon.com/exec/obidos/ISBN%3D0321150406/ref%3Dnosim/cafeaulaitA 
|
PURCHASE STYLUS STUDIO ONLINE TODAY!Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced! 
Download The World's Best XML IDE!Accelerate XML development with our award-winning XML IDE - Download a free trial today! Subscribe in XML format
|
|||||||||
