On Feb 19, 2014, at 12:34 PM, Toby Elliott <telli...@mozilla.com> wrote:
> This seems like the best answer beyond throwing time (and HAWK) out the > window entirely. We're carrying baggage from multiple different machines; > asking the client to sort that out seems doomed. >> But the fact remains that this seems like a spiderweb of complexity that >> doesn't really meet our needs… There are a couple reasons why Hawk is (arguably) better than bearer tokens, particularly over HTTP connections. All our requests are over HTTPS, so using Hawk is a bit of a belt-and-suspenders situation for us. Here are my recommendations: 1) Don't remove Hawk where we're currently using it. It will be too disruptive at this point in time. 2) Dramatically scale back the replay protection of Hawk. Hawk allows a time window of 1 min by default. I propose we change that to something big. A day, a week, a month, a year. Turn the knob until we stop seeing problems. This is a server side change, so we can keep cranking until the problem diminishes to a level we're comfortable with. We could turn it off completely (i.e., time window of infinity), but I think there is some value to keeping *some* replay protection beyond what is already provided by TLS. Even if we turn off the replay protection of Hawk, we still get other benefits from it (e.g., not leaking the actual token in every request). 3) Keep the servers in time sync. FWIW, my current thinking is to *not* include Hawk as part of our v1 Oauth2 implementation, but I believe we can easily introduce it in v-future versions, if we desire. We will not fail because TLS-level attackers replay users' requests. We are much more likely to fail by not being able to manage self-induced complexity and repelling users with frustrating experiences resulting from that complexity. -chris > It's unlikely to be an issue for external users, as their install will all be > on the same box in most cases. > > Toby > > > On Feb 19, 2014, at 12:31 PM, Mark Mayo <mm...@mozilla.com> wrote: > >> It's a reasonable requirement on the server side to say that all clocks >> *must* be within 5 seconds of real UTC, and if they're not, we're broken and >> should alarm for operator attentoin. We can/will/do have monitoring for this >> in prod. >> >> -Mark >> >> >> On Wed, Feb 19, 2014 at 12:20 PM, Richard Newman <rnew...@mozilla.com> wrote: >>> One approach we took was that the Server Timestamp is generally >>> distributed with every response from the server (The "Date:" header). >>> The client simply recorded the difference between the server and local >>> clock skew, and added that difference to the TS value used in the OAuth >>> headers. >> >> That's pretty much the approach Hawk takes: the timestamp range limitation >> approximates the circular buffer of nonces, and the clients use the server >> timestamp to correct their time for the purpose of authenticating to that >> particular server. >> >> The issue here is that we have three tiers of servers, each of which's clock >> might differ, the third tier of which can change (different storage >> servers), and a client clock that can be adjusted while we're working. Add >> in questionable latency and the temptation to persist skews across restarts, >> and things become complex -- and, I might add, complex without eliminating >> some non-trivial percentage of errors. >> >> The OpenSignal folks suggest using the realtime clock in combination with >> some kind of anchoring ping to simulate an independent monotonic clock on >> Android. That seems like a reasonable idea -- "fake NTP". >> >> >> _______________________________________________ >> Sync-dev mailing list >> Sync-dev@mozilla.org >> https://mail.mozilla.org/listinfo/sync-dev >> >> _______________________________________________ >> Sync-dev mailing list >> Sync-dev@mozilla.org >> https://mail.mozilla.org/listinfo/sync-dev > > _______________________________________________ > Sync-dev mailing list > Sync-dev@mozilla.org > https://mail.mozilla.org/listinfo/sync-dev
_______________________________________________ Sync-dev mailing list Sync-dev@mozilla.org https://mail.mozilla.org/listinfo/sync-dev
