RE: Require WWW clients to describe password/security

>----------
>From: 	Hallvard B Furuseth[SMTP:h.b.furuseth@usit.uio.no]
>Sent: 	Sunday, June 09, 1996 3:21 PM
>To: 	http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com
>Subject: 	Require WWW clients to describe password/security
>
>[  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.

Clients that care will refuse to send Basic. Browsers need to be
configurable to allow them to say that -- but that's not a protocol
issue.  Browsers should also probably remember sites that used Digest
Auth once, and insist on it later.
>
>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.

Ditto the above. No authentication scheme works if the client doesn't
>demand that it be used.
>
>One fix I can think of is to remove from the draft any claims of
>protection against man-in-the-middle or counterfeit servers:-(

We should clarify the security considerations sections to be more
explicit how to make sure that Digest is actually used, so that its
protections against MITM and counterfeit servers can be enjoyed.

>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...

Use Digest.  Basic is bad, no matter what clients do. If clients inist
>on Digest, then things are lots better.

Paul
>

Received on Sunday, 9 June 1996 19:33:18 UTC