Re[2]: Draft W3C TAG Finding "Passwords in the Clear" available for review

Hi Phillip,

I agree - in fact - the paragraph "...a simple way to stop web
crawlers..." should be removed.  I've never seen or even heard of that
idea before, nor is it sensible.  Everyone uses CAPTCHA's for that -
not passwords.

1) Its about giving the user a fighting chance.

Then you should educate people with web sites to use SSL.  A
self-signed cert and the appropriate browser security warning are
significantly better than letting Joe User give his password to any
sniffer who wants it (which is what happens anytime plaintext *or*
hashing takes place).

This draft is not about educating users, it's about technically
protecting them.  avoiding SSL is the exact opposite of protecting
them.

> the designs must be theoretically sound as well.

I agree

> I am currently working on a 'design checklist' for security
> usability which I am caling the 7 laws of security usability.

Wow. Big task. Here's my "brain dump" of everything you are up
against:-

http://www.owasp.org/index.php/Comprehensive_list_of_Threats_to_Authentication_Procedures_and_Data

> 3) It is reasonable to demand that a password should never be sent
> either en-clair or to an unauthenticated party

I definitely think so.  Like Amir said - people re-use passwords.  To
allow anyone to not protect them introduces a weak link everywhere.

> pay for a Trusted Third Party issued SSL certificate.
> * It must be possible for Web sites to authenticate users without
> cost 

self-signed certs are free.  Even IPSCA 3-month real certs are free.
Sure, they're not as good as signed certs, but they're a universe
better than plaintext or hashing.

> This is one of the problems I have with the assumptions in the
> OpenID world.

LOL - join the club.  Let me know if you need support at helping to
solve that one - maybe if enough of us complain, OpenID 3.0 will fix
this?

> 4) Passwords belong to users, users should decide who manages them.

Good point

> It follows therefore that any site which requires a password to be
> supplied ...

Well - technically - you've made a mistake already.  If passwords
belong to users, then there should never be any way for users to give
passwords to sites.  This comes back to the hashing problem again,
with the added annoyance of requiring universal user-agent support for
something secure as well.

Universal adoption of SSO might solve this though - since one the IdP
needs to know the users password.

> The only sites that should maintain databases of authentication
> credentials are sites that are providing a federated identity
> service.

LOL - I should read ahead before I reply :-)

> separate transactions according to the degree of risk involved

I had a dream some time ago (1983 in fact!) - and since you work for
Verisign, you might indulge my sentimentalism: imagine a pocket
calculator, the same size as a credit card.  A small screen, a keypad.
When you need to do a transaction, the screen tells you the amount,
you key in your PIN, and it's authorized.  My 1983 idea saw this
device connected via a smart-card reader, but we've got
bluetooth/USB/etc today.  This would solve everything :-)
No passwords move around.  No phishing or scams can filch victims
money.  No replays.  No SSL needed.  The only minor problem is that it
would eradicate fraud - which contributes billions of dollars to
banking and card-company profits (merchants pay for fraud - not
banks), which is why no such thing exists...

Kind Regards,
Chris Drake


Friday, February 15, 2008, 1:37:36 AM, you wrote:

HBP> "There are some cases where it is acceptable to transmit
HBP> passwords in the clear. One example is that placing a password on
HBP> a page can be used as a simple way to stop web crawlers without
HBP> really having to 'secure' the content. Administrators using a
HBP> clear text password need to be aware that passwords used for this
HBP> type of purpose SHOULD NOT re-use the same password in contexts
HBP> that are more sensitive."
HBP>  
HBP>  
HBP> I would phrase this as a 'not directly harmful' practice
HBP> rather than an 'acceptable' one.
HBP>  
HBP> I do not like schemes that teach users to repurpose
HBP> security channels. It means that when we try to educate users
HBP> about good practices we have to include exclusions and caveats to
HBP> deal with these corner cases.
HBP>  
HBP> The same effect can be achieved through a POST form, there
HBP> is no value to using a password field in this case and in fact it
HBP> is an encumberance.




HBP> From: public-usable-authentication-request@w3.org
HBP> [mailto:public-usable-authentication-request@w3.org] On Behalf Of
HBP> David Orchard
HBP> Sent: Wednesday, February 13, 2008 8:48 PM
HBP> To: public-usable-authentication@w3.org
HBP> Subject: Draft W3C TAG Finding "Passwords in the Clear" available for review



HBP> Dear Web Security Context WG,
HBP>  
HBP> On behalf of the W3C TAG, I would like to solicit your
HBP> review of the Draft TAG finding "Passwords in the Clear" [1]. 
HBP> Comments on this draft should be posted to www-tag@w3.org and are
HBP> appreciated.  We do not have a firm deadline but I'd like to
HBP> suggest March 7th 2008 as a rough timeframe for comments.
HBP>  
HBP> Cheers,
HBP> Dave Orchard

HBP>  
HBP> [1] http://www.w3.org/2001/tag/doc/passwordsInTheClear-52
HBP>  

Received on Thursday, 14 February 2008 18:26:16 UTC