RE: Encrypting basic card data

I'm not clear on what this is mitigating. If we're implementing things
for security then we need to start by outlining the threat, understanding
the risk/likelihood of any vulnerability, and then assess the cost of the
mitigation.

I can see some potential benefits for adding this (and we've discussed them
before) but this doesn't seem to be necessary for v1 given that basic card
is designed to be equivalent to autofill today.

On Sat, Jul 09, 2016 at 08:52:16, Adrian Hope-Bailie wrote:
> 
> Hi all,
> 
> 
> We discussed putting together a more sophisticated card payment method
> spec at the f2f but I wonder if we shouldn't raise the bar slightly for
> the basic card spec before we go to CR already?
> 
> 
> The obvious solution is encrypting the card data in the payment
> response. The challenge is deciding what key and cipher suite to use and
> that introduces a massive amount of complexity.
> 
> 
> We can use asymmetric crypto and the merchant can provide a public key
> in the request (either unique per transaction or not) which the payment
> app uses to encrypt the response data. This would not eliminate MiM
> attacks as a MiM could substitute the key for their own and still steal
> the credentials. It would however prevent sniffing data from this
> channel so that an attacker that is monitoring the events/logs but isn't
> able to actually intercept the messages is thwarted.
> 
> 
> I believe this is a simple enough solution that we could specify it as a
> minimum bar and all payment apps/browsers would be capable of
> implementing this from day 1. What do you think?
> 
> 
> Note: I'm leaving talk of a more sophisticated solution where the keys
> are bound to the merchant and can be verified by the payment app to
> another discussion, there was a decent size group of volunteers in
> London interested in exploring that topic.
> 
> 
> Adrian

Received on Sunday, 10 July 2016 08:30:33 UTC