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

 

-----Original Message-----
From: Chris Drake [mailto:christopher@pobox.com] 
Sent: Thursday, February 14, 2008 10:26 AM
To: Hallam-Baker, Phillip
Cc: David Orchard; public-usable-authentication@w3.org
Subject: 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 passwords 
HBP> in the clear. One example is that placing a password on a page can 
HBP> be used as a simple way to stop web crawlers without really having 
HBP> to 'secure' the content. Administrators using a clear text password 
HBP> need to be aware that passwords used for this type of purpose 
HBP> SHOULD NOT re-use the same password in contexts that are more 
HBP> sensitive."
HBP>  
HBP>  
HBP> I would phrase this as a 'not directly harmful' practice rather 
HBP> than an 'acceptable' one.
HBP>  
HBP> I do not like schemes that teach users to repurpose security 
HBP> channels. It means that when we try to educate users about good 
HBP> practices we have to include exclusions and caveats to deal with 
HBP> these corner cases.
HBP>  
HBP> The same effect can be achieved through a POST form, there is no 
HBP> value to using a password field in this case and in fact it is an 
HBP> 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 
HBP> for review



HBP> Dear Web Security Context WG,
HBP>  
HBP> On behalf of the W3C TAG, I would like to solicit your review of 
HBP> 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:49:31 UTC