- From: Mitar <mmitar@gmail.com>
- Date: Wed, 2 Mar 2016 03:52:43 -0800
- To: Crispin Cowan <crispin@microsoft.com>
- Cc: "noloader@gmail.com" <noloader@gmail.com>, "public-webappsec@w3.org" <public-webappsec@w3.org>
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