-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 15/05/2015 03:24, Kumar McMillan wrote: >> On May 13, 2015, at 11:48 PM, Ryan Kelly <[email protected] >> <mailto:[email protected]>> wrote: >> >>> - payments.mozilla.com <http://payments.mozilla.com> >>> <http://payments.mozilla.com> verifies the token on the server >>> and checks that it has the *payments* scope >> >> The key question here is: what power does a token with >> "payments" scope provide? If I were to somehow obtain a >> "payments" scope token tied to "[email protected] >> <mailto:[email protected]>", what would the Payments system >> let me do on your behalf? >> >> Can I use that token to initiate new transactions using your >> stored credit card details without any further authentication? > > Yes, they could make a purchase which includes access to saved > credit cards (full numbers obviously are not obtainable). > > The acquired product would only be attributed to the FxA user of > the token and funds would only be sent to the configured vendor. I > suppose one threat is where a stolen token could be used to put > purchases on someone else’s account but nothing is gained by the > attacker in that case.
Right, good point. As long as you trust Backup not to make extra payments to itself using the token then ISTM this should be fine. >> It that's not acceptable (which it certainly wouldn't be for a >> third-party relier) then we could try to come up with some >> clever extra step on the FxA side. For example, Payments could >> bounce you through a confirmation prompt on FxA, which proceeds >> transparently if you've got an active FxA session in that browser >> but prompts you to re-authenticate otherwise. > > That’s interesting. How could we bounce through with a potential > prompt? This sounds like something that would improve security > without adding friction because in the happy path the user would > have an active session. This would address the attack I mentioned > above. I haven't thought about it in much detail, but it could be that the payments iframe begins by redirecting to a 'promptless' oauth flow. If the user has an active FxA session that matches the payment token user, then we just redirect back with a confirmation. If not then we show a sign-in-to-continue page like the existing oauth flow. Purely hypothetical, but maybe useful. > Thanks for the feedback. It sounds like it’s ok to proceed with > token sharing, at least as a first pass. Yes, sounds good to me. Ryan -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iEYEARECAAYFAlVVHHoACgkQfI5S64uP50qJMQCfapFQOb/zV3HKHUeL63KN+qZC kAsAoLpwlTbBDEY3lPvulEL6Cffn2J4L =AMlD -----END PGP SIGNATURE----- _______________________________________________ Dev-fxacct mailing list [email protected] https://mail.mozilla.org/listinfo/dev-fxacct
