Doh. Fat-fingered my reply.... Resending to the list. > On 7/17/06, Eric Rescorla <[EMAIL PROTECTED]> wrote: > > > > In most such systems, the passwords are stored in the password > > database as a one-way hash of the password. > > Systems that use forms will often do this as well...
Yes, the heading "Plaintext Passwords" was intended to cover both Basic and Forms. > > IMPLEMENTATION ISSUES > > I'm given to understand that there are ways in which the Digest spec > > is unclear and that implementation and interoperability is fairly > > spotty. > > ...which makes it impossible to use the existing auth database with > Digest. If by "existing auth database" you mean the basic or form database, this is generally correct--though one could in fact implement an auth database that would work for both. > Digest's more extensive protection options are basically > unimplemented. By "more extensive protection options" do you mean the auth-int mode? I'm not familiar with what HTTP implementations do, but I'll note that SIP implementations will do auth-int. In any case, from the perspective of password capture, any form of digest is better than basic. > Digest is extremely underspecified wrt to encoding of > non-ascii characters. Some implementations respect the charset > parameter specified in SASL Digest (RFC 2831). Others use the encoding > of the page. No one is quite sure what IE does.* Mozilla uses UTF-8 > all the time. > > * <http://www.agileprogrammer.com/eightytwenty/archive/2006/05/04/14280.aspx> Right. This could obviously be the subject of a clarifying draft. > The only thing we can reasonably say is Basic+TLS, but that's sort of > silly, since many servers and some clients won't implement it. I'd > rather skip the collective game of pretend. Feel free to take this point up with the IESG. I doubt you'll find them very sympathetic, however. -Ekr
