Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

should we support non-HTTPS urls for in-app payments?

31 views
Skip to first unread message

Kumar McMillan

unread,
Apr 9, 2013, 6:29:08 PM4/9/13
to dev-w...@lists.mozilla.org, Raymond Forbes
For a developer to build an app with in-app payments she currently has to

1. host a web server at some domain and
2. that server must accept HTTPS connections with a valid cert. She cannot use a self-signed cert.

Is it important enough for the developer ecosystem to relax this restriction and allow HTTP URLs?

If a developer self-hosts their domain it is pretty costly to get an HTTPS cert and this would be a barrier to entry. Many services like Heroku, App Engine, OpenShift, etc, will provide HTTPS on a shared domain though.


Why HTTPS? The restriction applies to when the Firefox Marketplace does a server to server post with a JWT containing the result of a purchase. This JWT is a blob of JSON that contains info about the product. It does *not* contain user data unless the developer put an email or something in the productData field but that would be weird. In raw form, the JWT is a base64 encoded string of JSON + a signature.

Here's detailed info about how notifications work: https://developer.mozilla.org/en-US/docs/Apps/Publishing/In-app_payments#Processing_postbacks_on_the_server

Example JWT that would be sent over the wire in plain text (after decoding it):

{
"iss": "marketplace.firefox.com",
"aud": APPLICATION_KEY,
"typ": "mozilla/payments/pay/postback/v1",
"exp": 1337370900,
"iat": 1337360900,
"request": {
"id": "915c07fc-87df-46e5-9513-45cb6e504e39",
"pricePoint": 1,
"name": "Magical Unicorn",
"description": "Adventure Game item",
"productData": "user_id=1234&my_session_id=XYZ",
"postbackURL": "https://yourapp.com/payments/postback",
"chargebackURL": "https://yourapp.com/payments/chargeback"
},
"response": {
"transactionID": "webpay:84294ec6-7352-4dc7-90fd-3d3dd36377e9"
}
}

Matt Basta

unread,
Apr 9, 2013, 6:57:24 PM4/9/13
to Kumar McMillan, dev-w...@lists.mozilla.org, Raymond Forbes
Correct me if I'm wrong, but if a third party intercepted the JWT for the purchase, they couldn't falsify information in that JWT or somehow create their own fraudulent JWT. And as you said, user privacy at a high level isn't impacted since there's no personal information in the JWT. Since that's the case (AFAIK), I'd say it's safe to not require HTTPS.
_______________________________________________
dev-webapps mailing list
dev-w...@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-webapps

Kumar McMillan

unread,
Apr 9, 2013, 7:15:17 PM4/9/13
to Matt Basta, dev-w...@lists.mozilla.org, Raymond Forbes

On Apr 9, 2013, at 5:57 PM, Matt Basta <mba...@mozilla.com> wrote:

> Correct me if I'm wrong, but if a third party intercepted the JWT for the purchase, they couldn't falsify information in that JWT or somehow create their own fraudulent JWT.

Correct. This was so obvious in my own head that I forgot to mention it :) An attacker can't intercept an HTTP request and *alter* the outcome of a payment. The JWT is signed with a secret (shared) key so both parties will know if it was tampered with.

Paul Theriault

unread,
Apr 9, 2013, 8:10:48 PM4/9/13
to Kumar McMillan, dev-w...@lists.mozilla.org, Raymond Forbes, Matt Basta
Hmm. What about replay of payment messages? Could that be an issue? Or is it up to an app to take care this risk? Ie, if I can intercept a payment message (which would require significant network access admittedly), can I just replay 1000 times to get 1000 magical unicorns?

My other concern with this is that any app that does not have SSL has no business having user accounts, let alone taking payments (I am assuming if their postback URLs are not SSL, then their app is not SSL either - is this valid?). Is this an unrealistic expectation? I'm mainly worried about attackers injecting arbitrary scripts into insecure apps.

Thoughts?

Andy McKay

unread,
Apr 9, 2013, 8:13:48 PM4/9/13
to Kumar McMillan, dev-w...@lists.mozilla.org, Raymond Forbes, Matt Basta

On 2013-04-09, at 4:15 PM, Kumar McMillan <kmcm...@mozilla.com> wrote:
> On Apr 9, 2013, at 5:57 PM, Matt Basta <mba...@mozilla.com> wrote:
>
>> Correct me if I'm wrong, but if a third party intercepted the JWT for the purchase, they couldn't falsify information in that JWT or somehow create their own fraudulent JWT.
>
> Correct. This was so obvious in my own head that I forgot to mention it :) An attacker can't intercept an HTTP request and *alter* the outcome of a payment. The JWT is signed with a secret (shared) key so both parties will know if it was tampered with.
>
>> And as you said, user privacy at a high level isn't impacted since there's no personal information in the JWT. Since that's the case (AFAIK), I'd say it's safe to not require HTTPS.

I suppose it goes without saying we need to remind developers to verify the signature. Especially if over HTTP.

If the item was for something that can be repeatedly purchased (say a new life in a game). Can I MITM it, then just keep replaying the request? I guess the developer will checking for things like transaction id or id? Can I just change that and keep replaying it?

Andy McKay

unread,
Apr 9, 2013, 8:16:05 PM4/9/13
to Kumar McMillan, dev-w...@lists.mozilla.org, Raymond Forbes, Matt Basta

On 2013-04-09, at 5:13 PM, Andy McKay <amc...@mozilla.com> wrote:
> If the item was for something that can be repeatedly purchased (say a new life in a game). Can I MITM it, then just keep replaying the request? I guess the developer will checking for things like transaction id or id? Can I just change that and keep replaying it?

Ah no, because its signed, so can't tamper with it.

Kumar McMillan

unread,
Apr 9, 2013, 8:45:18 PM4/9/13
to Paul Theriault, dev-w...@lists.mozilla.org, Raymond Forbes, Matt Basta

On Apr 9, 2013, at 7:10 PM, Paul Theriault <pther...@mozilla.com> wrote:

> Hmm. What about replay of payment messages? Could that be an issue? Or is it up to an app to take care this risk? Ie, if I can intercept a payment message (which would require significant network access admittedly), can I just replay 1000 times to get 1000 magical unicorns?

As Andy mentioned, you could replay the payment message but you can't tamper with it. So, yes, it would be up to the app to protect against replays. They would typically start it with their own transaction ID and when they receive a payment message they would reject it if that ID had already been processed. Replays may still be possible with HTTPS because server logs are usually leaky but I guess HTTPS would mitigate it.

>
> My other concern with this is that any app that does not have SSL has no business having user accounts, let alone taking payments (I am assuming if their postback URLs are not SSL, then their app is not SSL either - is this valid?). Is this an unrealistic expectation? I'm mainly worried about attackers injecting arbitrary scripts into insecure apps.

I think it's valid that the app might not have HTTPS and still be secure enough for payments. For example, it might use client-side Persona for auth which I don't think requires HTTPS on the backend verifier to be secure.

>
> Thoughts?
>
>
>
>
>
>
>
>
>
>
>
> On Apr 10, 2013, at 9:15 AM, Kumar McMillan wrote:
>
>>
>> On Apr 9, 2013, at 5:57 PM, Matt Basta <mba...@mozilla.com> wrote:
>>
>>> Correct me if I'm wrong, but if a third party intercepted the JWT for the purchase, they couldn't falsify information in that JWT or somehow create their own fraudulent JWT.
>>
>> Correct. This was so obvious in my own head that I forgot to mention it :) An attacker can't intercept an HTTP request and *alter* the outcome of a payment. The JWT is signed with a secret (shared) key so both parties will know if it was tampered with.
>>
>>> And as you said, user privacy at a high level isn't impacted since there's no personal information in the JWT. Since that's the case (AFAIK), I'd say it's safe to not require HTTPS.
>>>
>>>
>>>

Paul Theriault

unread,
Apr 9, 2013, 8:50:45 PM4/9/13
to Andy McKay, Kumar McMillan, dev-w...@lists.mozilla.org, Matt Basta, Raymond Forbes

On Apr 10, 2013, at 10:16 AM, Andy McKay wrote:

>
> On 2013-04-09, at 5:13 PM, Andy McKay <amc...@mozilla.com> wrote:
>> If the item was for something that can be repeatedly purchased (say a new life in a game). Can I MITM it, then just keep replaying the request? I guess the developer will checking for things like transaction id or id? Can I just change that and keep replaying it?
>
> Ah no, because its signed, so can't tamper with it.

But what about not changing anything, and just replaying it (e.g. buy one month worth of access to a service, replay to get many months worth of access)

Again though, if you are an attacker who has the ability to MITM all traffic to a non-ssl website, you pretty much already win (sessions ids, passwords, inject scripts etc etc)

Fred Wenzel

unread,
Apr 9, 2013, 10:15:49 PM4/9/13
to Kumar McMillan, dev-w...@lists.mozilla.org, Raymond Forbes, Matt Basta
Where does the shared secret come from (i.e., how does it get shared
between app and server)? If it ships with the app, an attacker can just
fish it out of their instance of the app and off they go. If it's sent
over the wire, you need a method to keep it secret; like HTTPS or a
Diffie-Hellman key exchange.

~F

Andy McKay

unread,
Apr 10, 2013, 12:37:34 PM4/10/13
to Fred Wenzel, Kumar McMillan, dev-w...@lists.mozilla.org, Matt Basta, Raymond Forbes
Probably the only big remaining issue is perception. If we allow this, some justification why we think its ok in the documentation would be a good idea.

Kumar McMillan

unread,
Apr 10, 2013, 12:54:41 PM4/10/13
to Fred Wenzel, dev-w...@lists.mozilla.org, Raymond Forbes, Matt Basta

On Apr 9, 2013, at 9:15 PM, Fred Wenzel <fwe...@mozilla.com> wrote:

> Where does the shared secret come from (i.e., how does it get shared
> between app and server)? If it ships with the app, an attacker can just
> fish it out of their instance of the app and off they go. If it's sent
> over the wire, you need a method to keep it secret; like HTTPS or a
> Diffie-Hellman key exchange.

It's a shared private secret. The app has a copy that it must keep on its server and the payment provider (Mozilla's Webpay) must also keep a copy securely on its server. All communication is signed with the secret, i.e. no secret is ever passed over the wire, only signatures derived from the secret. So http doesn't really pose a problem here because the signatures are strong (hmac/sha256). The strength can be increased at any time if we choose to without altering the protocol.

Kumar McMillan

unread,
Apr 10, 2013, 1:20:13 PM4/10/13
to Paul Theriault, dev-w...@lists.mozilla.org, Andy McKay, Matt Basta, Raymond Forbes

On Apr 9, 2013, at 7:50 PM, Paul Theriault <pther...@mozilla.com> wrote:

>
> On Apr 10, 2013, at 10:16 AM, Andy McKay wrote:
>
>>
>> On 2013-04-09, at 5:13 PM, Andy McKay <amc...@mozilla.com> wrote:
>>> If the item was for something that can be repeatedly purchased (say a new life in a game). Can I MITM it, then just keep replaying the request? I guess the developer will checking for things like transaction id or id? Can I just change that and keep replaying it?
>>
>> Ah no, because its signed, so can't tamper with it.
>
> But what about not changing anything, and just replaying it (e.g. buy one month worth of access to a service, replay to get many months worth of access)

If an app server doesn't use some kind of nonce (e.g. transaction ID) then it's susceptible to replays. I'd like to refer to this from now on as the 1000 Unicorns Problem :) We should document it to make app developers more aware.

JWTs always have an expiration time though which mitigates replays. We currently have that set to 1 hour but we could shorten it. The thing to be careful of here is clock skew on the receiving end.

It looks like an official nonce is being discussed for JOSE (the latest effort at standardizing JWT) http://www.mail-archive.com/jo...@ietf.org/msg00763.html

I think it would be good to have official nonce support in JWT because expirations aren't enough. OTOH you'd need some kind of memory storage to do nonce checks which would make JWT libraries more complex. Ephemeral storage like memcache should be enough because after that the expiration will catch replays.

>
> Again though, if you are an attacker who has the ability to MITM all traffic to a non-ssl website, you pretty much already win (sessions ids, passwords, inject scripts etc etc)
>

Raymond Forbes

unread,
Apr 10, 2013, 1:38:56 PM4/10/13
to Kumar McMillan, dev-w...@lists.mozilla.org, Fred Wenzel, Matt Basta
So, in an effort to eliminate confusion, let's pull out the
documentation that Kumar and I made to help visualize what is being
asked.

https://wiki.mozilla.org/Apps/ID_and_Payments#Payments_Data_Flow_Diagram

so, looking at this the one fear I have is it appears we would be
moving the PIN over the clear.

-r

Lucas Adamski

unread,
Apr 10, 2013, 1:41:28 PM4/10/13
to Kumar McMillan, dev-w...@lists.mozilla.org, Andy McKay, Paul Theriault, Matt Basta, Raymond Forbes
On 4/10/2013 10:20 AM, Kumar McMillan wrote:
> t not changing anything, and just replaying it (e.g. buy one month worth of access to a service, replay to get many months worth of access)
> If an app server doesn't use some kind of nonce (e.g. transaction ID) then it's susceptible to replays. I'd like to refer to this from now on as the 1000 Unicorns Problem :) We should document it to make app developers more aware.
>
> JWTs always have an expiration time though which mitigates replays. We currently have that set to 1 hour but we could shorten it. The thing to be careful of here is clock skew on the receiving end.
>
> It looks like an official nonce is being discussed for JOSE (the latest effort at standardizing JWT) http://www.mail-archive.com/jo...@ietf.org/msg00763.html
>
> I think it would be good to have official nonce support in JWT because expirations aren't enough. OTOH you'd need some kind of memory storage to do nonce checks which would make JWT libraries more complex. Ephemeral storage like memcache should be enough because after that the expiration will catch replays.

SSL is easy. This stuff seems hard.
Lucas.

Kumar McMillan

unread,
Apr 10, 2013, 1:57:53 PM4/10/13
to Raymond Forbes, dev-w...@lists.mozilla.org, Fred Wenzel, Matt Basta

On Apr 10, 2013, at 12:38 PM, Raymond Forbes <rfo...@mozilla.com> wrote:

> So, in an effort to eliminate confusion, let's pull out the
> documentation that Kumar and I made to help visualize what is being
> asked.
>
> https://wiki.mozilla.org/Apps/ID_and_Payments#Payments_Data_Flow_Diagram
>
> so, looking at this the one fear I have is it appears we would be
> moving the PIN over the clear.

No, not at all. There is currently a hard HTTPS requirement for any payment provider implementation (e.g. production is at https://marketplace.firefox.com/mozpay/ ). The topic of this thread does not apply to that at all.

This is about removing the hard HTTPS requirement only for external app servers. For example, let's say http://myadventuregame.com/ is an app that accepts in-app payments. Currently we require that app to have an HTTPS url in order to receive server to server payment notices. That is, the developer has to purchase a valid cert before she can *make* any money.

_

I am hearing that relaxing HTTPS makes the risk of replay attacks greater if the app is not coded correctly. However, this seems like something we could just warn about in the docs with a *big red* banner, no?

My main concern is that purchasing an SSL cert is going to block some devs from getting involved with payments but I don't know if that's a realistic concern or not. SSL certs are not cheap.

It looks like Facebook apps made this shift too which may have shut out some indie developers http://www.wpcode.net/fb-ssl.html/ But maybe it's better for security to force HTTPS on all our apps?

Raymond Forbes

unread,
Apr 10, 2013, 2:01:22 PM4/10/13
to Kumar McMillan, dev-w...@lists.mozilla.org, Fred Wenzel, Matt Basta
oops, yup, you would think i would look at my own diagram. :)

To be clear to everybody, Kumar is talking about allowing the
connection between the 3rd party app and the client (e.g. the phone) be
non-ssl. From what we have diagrammed the only data being passed is
the JWT token. (I realize that was established but hopefully this
diagram helps make it more clear for people)

-r

Raymond Forbes

unread,
Apr 10, 2013, 2:04:04 PM4/10/13
to dev-w...@lists.mozilla.org
To respond to this, I agree for the most part with Kumar. We could
document with something like "if you insist on not using SSL make sure
your app is coded correctly to prevent replay attacks" kinda thing.

I will say, SSL certs are not that expensive, at least not in my experience.

-r

Kumar McMillan

unread,
Apr 10, 2013, 2:04:38 PM4/10/13
to Raymond Forbes, dev-w...@lists.mozilla.org, Fred Wenzel, Matt Basta

On Apr 10, 2013, at 1:01 PM, Raymond Forbes <rfo...@mozilla.com> wrote:

> oops, yup, you would think i would look at my own diagram. :)
>
> To be clear to everybody, Kumar is talking about allowing the
> connection between the 3rd party app and the client (e.g. the phone) be
> non-ssl.

Actually, it's even better than that. I'm talking about allowing a non-ssl connection between the 3rd party app and *the payment server* (e.g. Mozilla), not the phone. If it were the phone I'd be way more concerned. It would be hard to put a MITM proxy in front of Mozilla's servers. But there could be exploits in the 3rd party app server.

> From what we have diagrammed the only data being passed is
> the JWT token. (I realize that was established but hopefully this
> diagram helps make it more clear for people)
>
> -r

Curtis Koenig

unread,
Apr 10, 2013, 1:49:45 PM4/10/13
to Lucas Adamski, dev-w...@lists.mozilla.org, Kumar McMillan, Raymond Forbes, Paul Theriault, Andy McKay, Matt Basta
Great point Lucas, and with that I would ask what would be the point of having this particular communication path be unprotected? Wouldn't this just introduce other complexities we could avoid by securing our communication channels for something as critical as payments?
--
Curtis

Mark Giffin

unread,
Apr 10, 2013, 5:02:53 PM4/10/13
to Andy McKay, dev-w...@lists.mozilla.org
On 4/10/13 9:37 AM, Andy McKay wrote:
> Probably the only big remaining issue is perception. If we allow this, some justification why we think its ok in the documentation would be a good idea.
I heard that! I am watching this thread for doc info needed.

Mark

Mark Giffin

unread,
Apr 10, 2013, 5:20:46 PM4/10/13
to Raymond Forbes, dev-w...@lists.mozilla.org
On 4/10/13 11:04 AM, Raymond Forbes wrote:
> I will say, SSL certs are not that expensive, at least not in my experience.
To give a concrete example, the article Kumar posted earlier says certs
are $50 to $150 per year. Is that what you mean by expensive Kumar?

http://www.wpcode.net/fb-ssl.html

Mark


Kumar McMillan

unread,
Apr 10, 2013, 5:29:41 PM4/10/13
to Mark Giffin, dev-w...@lists.mozilla.org, Raymond Forbes

On Apr 10, 2013, at 4:20 PM, Mark Giffin <m1...@earthlink.net> wrote:

> On 4/10/13 11:04 AM, Raymond Forbes wrote:
>> I will say, SSL certs are not that expensive, at least not in my experience.
> To give a concrete example, the article Kumar posted earlier says certs are $50 to $150 per year. Is that what you mean by expensive Kumar?

Yes. Compare to $120+ per year for entry level web/cloud hosting; everything adds up. It just seems like an unnecessary barrier that would affect the bottom line for a web enabled business.

>
> http://www.wpcode.net/fb-ssl.html
>
> Mark

Gervase Markham

unread,
Apr 16, 2013, 7:10:12 AM4/16/13
to Kumar McMillan, Raymond Forbes, Fred Wenzel, Matt Basta
On 10/04/13 18:57, Kumar McMillan wrote:
> My main concern is that purchasing an SSL cert is going to block some
> devs from getting involved with payments but I don't know if that's a
> realistic concern or not. SSL certs are not cheap.

Yes, they are:

http://www.startssl.com/?app=1

Let us not make any decisions which are predicated on the cost of SSL
certificates being some sort of barrier. It really isn't. Even the ones
you pay for, if you get a DV cert, can be $20 or $30. And StartCom gives
them away (see above).

Gerv

Kumar McMillan

unread,
Apr 16, 2013, 6:58:08 PM4/16/13
to Mark Giffin, dev-w...@lists.mozilla.org, Raymond Forbes
Thanks for the feedback, all.

To summarize what I've heard:

- SSL certs can be bought cheaply in the US/Europe
- However, certs might be prohibitively expensive in some economies (like emerging markets)
- SSL is *not* required to make in-app payments secure
- SSL will probably make replay attacks harder if the app is susceptible to such

It sounds like it's safe to remove the SSL restriction so I filed this: https://bugzilla.mozilla.org/show_bug.cgi?id=862588

This will include documentation: a big red warning urging developers to use HTTPS if possible. Also, we can document replay attacks and how app developers can protect against them. They should be protecting against replays regardless of using HTTPS or not.

-Kumar

Raymond Forbes

unread,
Apr 17, 2013, 12:50:36 AM4/17/13
to Kumar McMillan, dev-w...@lists.mozilla.org, Mark Giffin
Also, we can document replay attacks and how app developers can protect against them. They should be protecting against replays regardless of using HTTPS or not.


Definitely this. This is super important, IMHO.

-r

Brian Smith

unread,
Apr 17, 2013, 5:18:41 PM4/17/13
to Kumar McMillan, dev-w...@lists.mozilla.org, Raymond Forbes, Mark Giffin
Kumar McMillan wrote:
> - SSL certs can be bought cheaply in the US/Europe
> - However, certs might be prohibitively expensive in some economies
> (like emerging markets)

Doesn't StartSSL not provide free certificates in all markets? Are there any of the initial target markets for which StartSSL does not provide free certificates?

> This will include documentation: a big red warning urging developers
> to use HTTPS if possible. Also, we can document replay attacks and
> how app developers can protect against them. They should be
> protecting against replays regardless of using HTTPS or not.

Are payments available for hosted apps, or just privileged/certified apps?

If payments are available for hosted apps, then that means that the prevention of replays would have to take place on the server, not in the app itself. Otherwise, the MitM that is forcing the replay would just remove the code that prevents the replays.

Cheers,
Brian

Kumar McMillan

unread,
Apr 17, 2013, 5:29:34 PM4/17/13
to Brian Smith, dev-w...@lists.mozilla.org, Raymond Forbes, Mark Giffin

On Apr 17, 2013, at 4:18 PM, Brian Smith <bsm...@mozilla.com> wrote:

> Kumar McMillan wrote:
>> - SSL certs can be bought cheaply in the US/Europe
>> - However, certs might be prohibitively expensive in some economies
>> (like emerging markets)
>
> Doesn't StartSSL not provide free certificates in all markets? Are there any of the initial target markets for which StartSSL does not provide free certificates?

Gerv linked to StartSSL but honestly it sounded too good to be true :) Is it really free as in free now and forever?

The cost of an SSL cert is only part of its complexities. The developer still has to install the cert on a server which may not be straight forward for a novice.

The main take-away from the thread so far is that SSL itself does not prevent a replay attack. An app should prevent against a replay attack regardless. If SSL is not directly solving any JWT threat then why should we *require* it? It just seems like an unnecessary road block.

>
>> This will include documentation: a big red warning urging developers
>> to use HTTPS if possible. Also, we can document replay attacks and
>> how app developers can protect against them. They should be
>> protecting against replays regardless of using HTTPS or not.
>
> Are payments available for hosted apps, or just privileged/certified apps?

payments are available to any web content at all (e.g. Firefox OS browser pages) but the notices must be verified server side. In the case of a packaged app, it must have a server hosted API it can use.

>
> If payments are available for hosted apps, then that means that the prevention of replays would have to take place on the server, not in the app itself. Otherwise, the MitM that is forcing the replay would just remove the code that prevents the replays.

Correct. Replays only apply to the app server and must be deflected there. A MitM would need to be positioned between Mozilla's data center and the app's web server.

>
> Cheers,
> Brian

Brian Smith

unread,
Apr 17, 2013, 8:04:04 PM4/17/13
to Kumar McMillan, dev-w...@lists.mozilla.org, Raymond Forbes, Mark Giffin
Kumar McMillan wrote:
> Gerv linked to StartSSL but honestly it sounded too good to be true
> :) Is it really free as in free now and forever?

http://www.startssl.com/?app=1

I don't think anything is "forever."

> > If payments are available for hosted apps, then that means that the
> > prevention of replays would have to take place on the server, not
> > in the app itself. Otherwise, the MitM that is forcing the replay
> > would just remove the code that prevents the replays.
>
> Correct. Replays only apply to the app server and must be deflected
> there. A MitM would need to be positioned between Mozilla's data
> center and the app's web server.

I see. Seems like we could look to AWS, PayPal, Google Checkout, etc. to see how they deal with these issues.

If there is a replay, does the user lose money or does the developer lose something? If it isn't possible to take money from the user without the user's consent then I think it seems OK to not require SSL if the developer is willing to take that risk, as long as no personally-identifiable information is being sent over an insecure channel. And, if it is possible for a replay to cost the user money without the user's consent then that seems like a more general and more serious problem, as the amount of money the user spends shouldn't depend on how well the app defends against replays.

Cheers,
Brian

Kumar McMillan

unread,
Apr 17, 2013, 9:15:15 PM4/17/13
to Brian Smith, dev-w...@lists.mozilla.org, Raymond Forbes, Mark Giffin

On Apr 17, 2013, at 7:04 PM, Brian Smith <bsm...@mozilla.com> wrote:
>>
>
> I see. Seems like we could look to AWS, PayPal, Google Checkout, etc. to see how they deal with these issues.

Google Wallet is nearly an identical system. I can't tell for sure but I think they do require HTTPS for postbacks: https://support.google.com/payments/answer/1385297?hl=en

>
> If there is a replay, does the user lose money or does the developer lose something?

Only the developer loses. A customer could use a replay attack to turn a legitimate purchase of 1 unicorn into 1000 unicorns at no extra charge (until the JWT expires) if the app does not prevent replays.

> If it isn't possible to take money from the user without the user's consent then I think it seems OK to not require SSL if the developer is willing to take that risk,

I can't think of how a user can lose money with a replay because postbacks do not affect how money is charged to the customer. All that happens over HTTPS either on Mozilla's servers or Bango's servers.

> as long as no personally-identifiable information is being sent over an insecure channel.

Correct. No personal info is in a JWT. It defines the product for sale, the price, description, and so on. Example: https://developer.mozilla.org/en-US/docs/Apps/Publishing/In-app_payments#Set_up_your_server_to_sign_JWTs

Handling user identity is out of scope for mozPay(). The way Marketplace does it is pass a custom transaction ID through the JWT that it can later reconcile with a user ID.

> And, if it is possible for a replay to cost the user money without the user's consent then that seems like a more general and more serious problem, as the amount of money the user spends shouldn't depend on how well the app defends against replays.

Anything the app does wrong would only cause the developer to lose money or make the customer unhappy. The app can do a lot of things wrong:
- it can choose not to wait for postback notices at all
- it can choose not to verify JWT signatures
- it can fail to ensure a transaction ID gets processed only once (replay attack)
- it can take someone's money and not deliver the goods

The documentation will hopefully make these risks clear. Mozilla will also notify developers when it encounters errors (like postback failures) and we may disable payment keys after a certain number of failures, complaints, etc.

>
> Cheers,
> Brian

0 new messages