- From: Hallvard B Furuseth <h.b.furuseth@usit.uio.no>
- Date: Mon, 10 Jun 1996 00:21:51 +0200 (MET DST)
- To: http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com
[ Warning: I may have misunderstood what I'm talking about here; I don't know much about WWW-security and I've got a feeling that someone must have thought about this before... ] I think draft-ietf-http-digest-aa-03.txt claims to be more secure than it is. Maybe other WWW security protocols too, I haven't checked. The draft says: > 3.3 Man in the Middle: > (...) a hostile proxy might spoof the client into > making a request the attacker wanted rather than one the client > wanted. Of course, this is still much harder than a comparable > attack against Basic Authentication. > > 3.4 Spoofing by Counterfeit Servers: > Basic Authentication is vulnerable to spoofing by counterfeit servers. > (...) This type of attack is not possible with Digest Authentication. If I set up a server with Digest Authentication, a Man in the Middle or Counterfeit Server could simply remove it and ask the client for Basic Authentication instead. The user will type in his password, "knowing" that it cannot be decrypted. Similarly, 2.1 Specification of Digest Headers: > <message-digest> is computed by the same algorithm given > above for the body of the client request. This allows the > client to verify that the body of the response has not been > changed en-route. Except if the party who changed the body en-route, also removed the optional message="<message-digest>" component. One fix I can think of is to remove from the draft any claims of protection against man-in-the-middle or counterfeit servers:-( Another is to demand that when clients ask interactively for a password, they inform the user in a *simple and standardized* way how the password is vulnerable, and where it is sent. * Simple - so that a novice can understand it (though of course a non-novice might configure the client to give more detailed information as well), * Standardized - so that an URL which asks for passwords, can have client-independent documentation with a concise, easily understood checklist the user can go through before he surrenders his password to the Web. A third fix is to tell me that I'm wrong:-) Sigh -- I didn't want to learn that much about WWW security; all I wanted was to write a simple WWW service which authenticates the user via his UNIX password... Regards, Hallvard
Received on Sunday, 9 June 1996 15:27:38 UTC