- From: Thomas Roessler <tlr@w3.org>
- Date: Wed, 12 Jul 2006 18:29:11 -0400
- To: spam filter <spam+w3c@jeff-nelson.com>
- Cc: Amir Herzberg <amir.herzberg@gmail.com>, Mary Ellen Zurko <Mary_Ellen_Zurko@notesdev.ibm.com>, public-usable-authentication@w3.org
On 2006-07-05 11:15:23 -0700, spam filter wrote: >> * a W3C Recommendation that describes an annotation >> mechanism that supports at least HTTP Digest >> Authentication, and possibly other authentication >> mechanisms as the working group sees fit > I'm not as familar with these requirements. It looks like > we're specifying an annotation of authentication meta-data. > Would we reference some other standard to provide the > authentication mechanisms? The basic idea is that, currently, HTML forms are used to ask for credentials such as passwords; the credentials are then submitted by way of HTTP POST. If there are protocol-level authentication mechanisms (such as Digest) available, then there is no way to dispatch the credentials to these mechanisms. The idea is to tell the user agent that such a mechanism is available, and that he can please dispatch the credentials to that mechanism, as opposed to usual form submission. > I'm not sure about calling out HTTP Digest Authentication, > since its broken. The offline dictionary attack on the > digest credential requires under 1 second of CPU time to > break most passwords. Rather, we could define an annotation > which is implementation neutral and agree on some > specification for picking the implementation. To some extent, that's the purpose of the "and possibly other mechanisms as the working group sees fit" language. > http://www.w3.org/2005/Security/wsc-charter > > >Current Web user agents communicate only a small portion of available > security context information to users in a way that is easily > perceived and understood. Other secontext context information that > might be available to user agents and possibly helpful to users is > either not presented, or presented in a way that is not understood by > users, and hence useless or confusing. This information ranges from > logotypes and company names and addresses that might be present in PKI > certificates, to the user agent's memory of past activities. > > >Where the mechanisms that are used to communicate context information > can be overridden by Web content, they also open the scene for > attackers serving fake security indicators. > > Could we mention personalization and/or unspoofability in this > charter? Or is it the intent that be covered by some other working > group? For example, how is this edit? > > >Current Web user agents communicate only a small portion of available > security context information to users in a way that is easily > perceived and understood. Other security context information that > might be available to user agents and possibly helpful to users is > either not presented, or presented in a way that is not understood or > spoofable, and hence useless or untrustworthy. This information > ranges from personalization, to logotypes and PKI certificate > meta-data, to the user agent's memory of past activities. > > > "can be overridden by Web content" is a tricky phrase. I would say > "can be effectively spoofed by Web content" as a more precise, 1 > sentence description of the threat model. These are a bit different: "Overridden" refers to scripting's ability to remove some elements from the display. "Spoof" includes things like the picture in picture attack, which is much more tricky to counter. > I would expect a solution to address the picture in picture > attack and incorporate sufficient training of users in > recognizing spoofing attacks. > > For example, a solution which allows for personalization may > not be sufficient if it doesn't train the user to utilize > the personalization and recognize spoof attacks on that > personalization. I'll play with some edits to the scope text to take up these points. -- Thomas Roessler, W3C <tlr@w3.org>
Received on Wednesday, 12 July 2006 22:30:31 UTC