- From: Jonathan Rees <jar@creativecommons.org>
- Date: Tue, 7 Oct 2008 13:14:36 -0400
- To: David Orchard <orchard@pacificspirit.com>
- Cc: "www-tag@w3.org" <www-tag@w3.org>
At the F2F we talked about this text "Good practice: Clear text passwords are a serious security risk, though sometimes are acceptable." We went over this for quite a while, as I remember, without conclusion. It was noted that one problem was that this GPN does not have the grammatical form of a good practice note because it doesn't give any advice. One proposed fix was to remove the box label "Good practice". This makes sense, although it leaves one a bit uneasy about what is being said or why. Let me suggest another approach. One can turn it into advice by saying something of the form "Good practice: Clear text passwords are a serious security risk. Transmit passwords in the clear only when ...." It was pointed out that we don't want to be in the business of telling people specifically when they're acceptable and when they're not. True, but I'd like to suggest that this form of fix might still work if the completion of this sentence were sufficiently tautologous. For example: "Good practice: Clear text passwords are a serious security risk. Transmit passwords in the clear only in applications that do not require any assurance of security." or some similar wording ("do not need to be secure", "where this substantial risk is acceptable", "where security compromises are acceptable", etc.). ... and then maybe remind developers / site administrators that users of passwords transmitted in this way must (MUST?) be told in no uncertain terms that such passwords should be treated as public knowledge and shouldn't be used to protect anything that matters. (Or would such secondary advice be seen as encouraging password transmission in the clear?) Just a thought. Jonathan On Sep 12, 2008, at 7:30 PM, David Orchard wrote: > Dear TAG, > > I have done a number of small edits to the Passwords in the Clear > finding, mostly adding material. It is available at > http://www.w3.org/2001/tag/doc/passwordsInTheClear-52 > http://www.w3.org/2001/tag/doc/passwordsInTheClear-52-20080912.html > > I feel that we have reached the point where we are simply not going > to get consensus outside of the TAG on the principle guidance of the > finding. Roughly speaking, there is a spectrum of positions: > 1) Clear text passwords never ok, digest authentication never ok. > This is exemplified by some members of WS-SC, the XHTML2 WG's > response [1], and Simon Kissane [2] > 2) Clear text passwords never ok, digest authentication ok. Current > document status. This or #3 supported by Paul Libbrecht [3] - he > only mentions digest ok, nothing about clear text passwords. > 3) Clear text passwords sometimes ok (that's life), digest > authentication ok. This is exemplified by the W3C web site, and > thread in [4], including strong statement by Chris Drake in [5] > > Chris had an interesting way out in "Preventing cleartext or > equivalent password transmission requires SSL or custom server/ > client components designed to negotiate secure sessions." > > Other comments > - XHTML2 suggested adding section on removing contents of password > fields from the cache [1]. Done. > - explicitly mention client side certificates [2]. done. > - two factor authentication. [2]. done. > - other desktop single signon technologies, such as unix based [2]. > Not done just because the document doesn't need to be exhaustive. > - Update text to more clearly require that non-ssl agents should use > salted hashed passwords [6]. Done > - add AtomPub using ws-security username password token [6]. Done > - Explicitly mention new security specifications like OpenId and > OAuth that do not require username/password exchange. [6]. Done. > > Cheers, > Dave > > [1] http://lists.w3.org/Archives/Public/www-tag/2008Jul/0086.html > [2] http://lists.w3.org/Archives/Public/www-tag/2008Jun/0126.html > [3] http://lists.w3.org/Archives/Public/www-tag/2008Jun/0127.html > [4] http://lists.w3.org/Archives/Public/www-tag/2008Jun/0106.html > [5] http://lists.w3.org/Archives/Public/www-tag/2008Jun/0111.html > [6] http://lists.w3.org/Archives/Public/www-tag/2008Jun/0024.html
Received on Tuesday, 7 October 2008 17:15:14 UTC