Re: Using client certificates for signing

Hi!

On Tue, Mar 1, 2016 at 10:26 PM, Crispin Cowan <crispin@microsoft.com> wrote:
> 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".

What phishing is there? Where is the harm in user authenticating
against paypai.com with his client certificate? And how again is this
different from user entering their username and password into
paypai.com? To me this is a problem of phishing/confusing the user
which is orthogonal to the question of what form should be the
authentication mechanism. Should it be username/password or a long
bytestring representing the public key.

Just to be clear, user's private key never leaves the browser. It is
potentially only used by the browser to sign data.

So my concrete proposal on the table is:

- let's introduce <input type="signature" name="sig"> form element
- if the form element is present, on submission browser prompts the
user to select the client-certificate using trusted UI
- it combines form payload with URL requesting the signature, and
signs this combined data (maybe we can also automatically include
timestamp and some nonce, or some other extra metadata)
- stores the result into the "sig" form field
- submits the form

Certificate never leaves the browser. Signature cannot be reused
elsewhere, it is clear for which website it is. But signature can be
verified by the 3rd party and it can be legally bound. Of course, 3rd
party would in the example above detect that the signature is for
paypai.com and not paypal.com. Even if the user was tricked, the
verified (a program) would detect the URL mismatch, the same how we
detect these days SSL certificate mismatch.


-- 
http://mitar.tnode.com/
https://twitter.com/mitar_m

Received on Wednesday, 2 March 2016 11:53:12 UTC