On 8/9/13 8:28 AM, Nick Alexander wrote:
> If we have the jelly do the auth dance (and return some set of tokens
> to the client?), then I think we're changing the TOFU + SRP security
> model of the auth server pretty significantly. But I suppose such
> issues are well enough understood from the Persona shim case that we'd
> be comfortable having served jelly handle user passwords? I'm scared.
I'm worried about that too. It changes the security model, specifically
the "your class-B data is safe unless X happens" disclaimer, from:
old X: You type your password into something other than good FF browser
chrome: either you use some web-content bridge, or somebody
pushes a doctored FF update to you (SSL attack during update, or
deliberate action by our servers), or compromises your computer
new X: Old X plus: somebody gives you a doctored jelly page (SSL attack
during login, or deliberate action by our servers)
A sufficiently paranoid user could protect themselves against a doctored
FF update by turning off auto-update, or comparing their browser
executable against their friends' copies (e.g. run Debian's version,
which has its own signed-update system, or use the ESR version your IT
department has approved).
We don't currently have any way to protect against a doctored jelly
page. Firefox should have TLS cert pinning soon, which reduces the SSL
threat considerably, but doesn't remove the deliberate-action-by-Mozilla
vector.
I recognize the decoupling/update benefits of the approach.. I'd be more
comfortable with it if I knew that is was temporary, and that our plan
was to bake the implementation into the browser ("absorb the jelly"?)
within a year or so. I suspect that won't happen, though, as the
benefits of dynamically updating that code are pretty compelling.
cheers,
-Brian
_______________________________________________
Sync-dev mailing list
[email protected]
https://mail.mozilla.org/listinfo/sync-dev
