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
On 10 Apr, 2013, at 13:41 PM, Lucas Adamski <[email protected]> wrote: > 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/[email protected]/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. > _______________________________________________ > dev-webapps mailing list > [email protected] > https://lists.mozilla.org/listinfo/dev-webapps _______________________________________________ dev-webapps mailing list [email protected] https://lists.mozilla.org/listinfo/dev-webapps
