Re: Trusted UIs. Was: proposed navigator.mozPay() changes

On Sep 16, 2013, at 2:47 PM, Anders Rundgren <anders.rundgren.net@gmail.com> wrote:

> Hi,
> This feature have been discussed for ages.  I heard about more than 15 years ago!
> 
> I believe this is not useful (unless you go to extremes such as dedicated PIN and signature terminals),  because it will only really work for security-conscious people but they only represent _a_fraction_ of the user-base.
> 
> Is then all doom and gloom?  No, the root of the problem is that (particularly in the US...) passwords and credit-card numbers is the norm and these are highly susceptible to various kinds of spoofing attacks.
> 
> One of the problems is articulated like this: If the user is tricked by logging in to "paypal.com.wondersite.com" this [presumably bad] site may get direct access to the user's payment credentials.
> This is not the case if the credentials are only usable in an _indirect_ way such as PKI.
> 
> What does this have to do with trusted UIs you may [rightfully] wonder?
> Not much, it is in the merchant end you have this problem because even if you have PKI you don't want evil merchants to withdraw money from your accounts.  The (IMO) best way to do that is through limiting access to your payment credentials so that it can only be used by trusted software.
> 
> The problem with trusted software is that it is either built-in or have to be installed and then automagically be trusted by the user.
> How can an average user have any opinion about what constitutes trusted software???
> IMO, they will _never_ be able to do that. 
> 
> Built-in trusted software is fine but put big constraints on the functionality and also suffer from serious standardization issues.
> 
> The solution which I'm advocating is that each payment network creates their own software but instead of letting the user decide if it is trustworthy or not, let the payment network's credentials declare which software is trusts.  This is BTW an almost exact copy of how current physical payment systems work.
> 
> http://webpki.org/papers/PKI/pki-webcrypto.pdf
> 
> This may not be (surely is not...) the perfect solution but I think it is workable.

Hi Anders.

Do you have a concrete example of how PKI can be used to mitigate phishing attacks? I want to understand it better. Are you envisioning some token system where a user never reveals their private key (obviously) but instead signs tokens to grant limited access to merchants? How would a non-technical user be protected against phishing for access to the token generator service?

Reducing exposure to entering sensitive credentials has been one of our strategies on Firefox OS as well. For example, we will soon have users sign into their phone on first run (via Mozilla Persona). Because of this, it will be odd for some other part of the phone to ask for a Persona password; it should raise suspicions. However, it's hard to make an average user "feel suspicious."

-Kumar

> 
> Disregarding implementation issues,
> What are the concrete alternatives including pros and cons?
> 
> Cheers,
> Anders
>

Received on Monday, 16 September 2013 20:42:58 UTC