RE: Using client certificates for signing

I agree with most all of what Jeff says.

Moreover, where Mitar says that asking the user if password authN is ok and cert authN is ok are the same thing, he (?) is right, but that is a *bad* thing. Phishing works against naïve users. This proposal *enables* phishing attacks against users with certificates. "Would you like to authenticate to paypai.com with Foo cert?" and a goodly number of users will say "yes".

*Don't* ask users technical security questions, it does not work. We have lots and lots of experience that proves that.

-----Original Message-----
From: Jeffrey Walton [mailto:noloader@gmail.com] 
Sent: Tuesday, March 1, 2016 6:39 PM
To: Mitar <mmitar@gmail.com>
Cc: public-webappsec@w3.org
Subject: Re: Using client certificates for signing

> To me it is really the same thing: I want to login into the website, I 
> choose username from my keychain to populate the password, or I choose 
> the certificate. But the certificate also allows one to sign stuff, 
> instead of business logic on the website assuring that because user 
> specified username and password at a given moment they are linked to 
> that same stuff.

The disconnect is higher than that...

When security architects place security controls for data, they do two things. They (1) classify the data, and then (2) they select controls appropriate for the data according to policies and procedures.

When dealing with low value data, passwords are OK and Usability can trump Security. User agents are allowed to dumb things, like coughing up the password to any server that answers, including the wrong one because the web security model removes the user and embraces "interception is a valid use case".

When dealing with medium and high value data, passwords are out and client certificates are in. The password is still used locally to protect the private key, but it is never put on the wire. We also model the user because we know the number on threat to the data is user phishing. With medium and high value data, Security trumps Usability.

The disconnects won't be reconciled until (1) the browsers become familiar with other methodologies to managing risk; (2) the security and risk model includes the user; and (3) browsers realize that "interception is not a valid use case" because that completely destroys one of the three states of data - data in transit (the other two being data at rest and data on display).

Browsers will also need to provide first class protected storage or an interface into the platform's protected storage. I think you've touched on some of the workflows, but we need first class protected support that does not depend on a iOS device pincode or passcode.

My guess is browsers will continue to misunderstand the larger picture, and continue to whither on client certificate support, and continue to be subjugated to low value data.

#NSA, GCHQ, law enforcement and bad guys luvz web (in)security.

Received on Wednesday, 2 March 2016 06:27:34 UTC