[passwordInTheClear-52]: A summary of where I think we are.

Hello Mez,

The TAG returned to discussion of passwordsInTheClear-52 at our telcon
yesterday [1].

There seem to be 3 issues remaining on the table:

1) Some regard that there are reasonable use cases for weak protection
of passwords - and demur against the Good Practice advice: "A client or
browser SHOULD NOT transmit passwords in clear text." 

2) Some editorial ambiguities in the current draft: for example, what is
the intent of: "Good Practice:  A server SHOULD NOT solicit any
passwords in clear text"  in particular the word 'solicit' and whether
it is intended to refer to the way in which user (via a UA) is asked for
a password, or the way in which the password is transfered between UA
and server, or both - different TAG members read this differently.

3) and probably more significantly, is the issue of the use of
'onsubmit' hooks to do client side processing of a form field:
Specifically client side encryption of a password field between submit
button-hit and the UA submit action (often a POST). If one were to
*want* to recommend (as many of the TAG do) that a UA should/must raise
a warning to the user when it 'detects' that a password field is about
to be transmitted in the clear, how is a UA to 'know' that effect of
'onsubmit' processing is to encrypt or generating a signature over the
password (plus some challenge) thereby making the transfer far from 'in
the clear'.

Notwithstanding 1) above; if the aim is to alert the user that a
password they are giving may be vulnerable to interception in transit
(because it is visible in clear text), then we have failed to identify a
reliable basis on which a UA can detect that situation. The tricky use
case is where an 'onsubmit' hooks is used to secure the password. 

In exploring this, some TAG members suggest that it may be better for a
UA to alert a user in the presense of indetermininate 'onsubmit'
behaviours than to supress such warning. Others are concerned that this
is a common use case at a number of sites (Yahoo! has been cited as one
significant case); that users would be alerted 'erroreously' because the
transfer is infact made secure by the action of the 'onsubmit' hook  -
the UA is just not able to tell; consequently the user will become
irritated by a repeating alert and either come to ignore it (in
general), or disable it (if they have the option to do so) - thus
defeating the purpose of having an alert in the first place.

In polling the TAG on: 

	"Is this a viable finding: 
	a) as it is? 
	b) Without the teeth? 
	c) If we added more caveats about lightweight passwords?" 

there seemed to be:

	a desire to find a reliable basis on which to advise that UA's
detect weakly protected password transfers; 

	a desire find wording that admitted some of the 'lightly'
protected door secnarios (1 above - and thread starting at [1])

	some sentiment that only a publication with some teeth would be
worth publishing ie. some means to determine fault and recommended
corrective action (my interpretation of 'teeth').

In your response to me [3], you suggest that 3) above (usage of onsumbit
hooks) is somewhat hypotheical. I think that a several TAG members would
need to be persuaded that the case is hypothetical. There is certainly a
belief that Yahoo! either have in the past or indeed continue to use
such mechanisms in some geographies - though at present, form where I
am, they do seem to be authenticating with https interactions.

FWIW: personnally I think that using the onsubmit mechanism to secure an
otherwise 'in-clear' exchange (ie. via http rather than https) while
'cute' is probably bad practice because the practice denies the UA the
ability to reliably warn the user that a password they are using may be
vulnerable. If the major sites that we thought were using that practice
have moved away from doing so (or never were doing it quite the way we
thought they were) I think it would be worthwhile advising against
practice.

It would be good to try to schedule some time so that you can discuss
this further with TAG members, however, your availability and the
impending summer season (if the weather ever gets better here :-) ) make
scheduling that a challenge. Maybe in the mean time we could continue
some discussion with the TAG on this thread.

Many thanks,

Stuart
--
[1] http://lists.w3.org/Archives/Public/www-tag/2006Nov/0085.html
[2] http://lists.w3.org/Archives/Member/tag/2007Jun/0050.html
--
Hewlett-Packard Limited registered Office: Cain Road, Bracknell, Berks
RG12 1HN
Registered No: 690597 England

Received on Wednesday, 27 June 2007 12:39:42 UTC