Keith Moore wrote on 6/10/07 23:33 -0400:
>>> Digest has a bad reputation particularly among Web App developers for
>>> a number of reasons, some inherent to the design and specification,
>>> some stemming from implementation and deployment choices.
>>>
>>
>> Nearly all is implementation.
>>
> ah, but what's the reason for all of those implementation-imposed
> constraints?
I would speculate it's because the following mandatory pieces of a complete
DIGEST-based solution were never written down:
* Client UI requirements
* How to store DIGEST H(A1) in a central authentication repository such as
LDAP or RADIUS in an interoperable fashion
* How web CGIs, PHP modules, etc. interface to the HTTP server's DIGEST support
* How to tie the DIGEST identity to whatever real identity system happens to
be deployed at the web site. From an IETF standards perspective, that
means getting the LDAP directory entry and/or RADIUS/DIAMETER attributes for
the user to the subsystem that needs that information. In practice this can
also involve a SQL database with unspecified keys and attributes.
* How a web page can securely associate branding with a DIGEST authentication
UI in the browser
* How to migrate an existing password repository using an arbitrary
one-way-function to store password verifiers to one that's DIGEST compatible,
and do so in a way that won't generate service calls from customers.
Since implementations already have all this infrastructure for plaintext
passwords (existing standards are sufficient due to plaintext simplicity), why
should they waste time doing a one-off version of all this work if there aren't
enough standards written for it to interoperate? Besides, DIGEST without TLS
is now so weak in a 10-cents-per-windows-zombie-CPU-week world that I question
the value of doing any of this work just for DIGEST.
- Chris