10.21.13 Engineering Progress Report for Firefox Accounts and Sync.next

Chris Karlof ckarlof at mozilla.com
Wed Nov 6 11:36:49 PST 2013


On Nov 6, 2013, at 3:57 AM, Lloyd Hilaiel <lhilaiel at mozilla.com> wrote:

> On Nov 6, 2013, at 12:36 AM, Chris Karlof <ckarlof at mozilla.com> wrote:
>> 
>>> 4. This seems like a nice isolated & well defined bit of work we could ||ize?
>>> 
>> 
>> It's possible. Key stretching isn't the only thing. We also need to land code to handle SRP natively as well. Plus there's testing and measuring it. After we implement, test, and measure, it still may not be fast enough, and we'll have to do more work. Too much risk for this insane schedule. Jed and Co. don't have a complete working system yet. If someone magically has time (that shouldn't' be working on more pressing things) to land and measure a native PBKDF2 and SRP implementation, then I welcome the help. But there's no guarantee that Jed and Co will have time to integrate it.
>> 
>> Did I mention the car is still apart on the garage floor? Let's support Jed and Co. to put the car back together and get it running, and then we can pimp it out. 
> 
> This sounds pragmatic and right on.  I’m fine with launching with raw_password if you guys are.
> 
> So that’s the short term solution, let’s do it.
> 
> Longer term though:  We defined a security architecture optimized for sync originally in picl-idp.  We’ve now learned that the scope of picl-idp is greatly expanded, and we must support firefoxos and web based authentication.  To do so we are reverting to raw_password.
> 
> Does it make sense here to keep an open mid to the possibility that an authentication protocol of reduced complexity that we can implement at pace everywhere might be superior to the original architecture, all things considered?
> 

The simplest thing to do is for the auth mechanism to be (roughly) the same everywhere. That's one benefit of the /raw_password API. 

You raise a good point, and it's one that Warner and I have discussed: if we are playing so fast and loose to support auth everywhere, maybe this design we made for sync isn't the right fit.

One thing we've discussed is doing the optional second password approach, like Chrome Sync. Your primary auth password would be protected by some modest stretching as you suggest and just be submitted directly over SSL, but your optional Firefox Sync password would only be entered into native UI and slide you down the crypto chute. Or we can make paring awesome.

FWIW, the current architecture is flexible in whether or not it does scrypt and how many rounds of PBKDF it does. SRP is baked in, but that's not a big deal. 

More data? We need a native crypto implementation for FxOS and we need to evaluate its performance. We also need a working FxA client on FxOS, which we don't have yet. :)

-chris



> I like SRP and scrypt, but our sec. arch is only as strong as the weakest link.  It may turn out that a simple PBKDF2 approach with partial stretching in limited environments is both simpler, and more secure.
> 
> What data do we require to understand what a viable authentication protocol would be for our lowest common denominators?  (IE8 and FirefoxOS).  How hard is it to acquire that data?
> 
> lloyd
> 
>> Here's some discussion of the /raw_password API. It actually isn't that bad, in particular, it's future compatible with native implementations of key stretching and SRP:
>> 
>> https://github.com/mozilla/picl-idp/blob/master/docs/api.md#raw_password-discussion
>> 
>> -chris
>> 
>>> <3,
>>> lloyd
>>> 
>>> [1]: http://people.mozilla.org/~lhilaiel/pbkdf2/
>>> [2]: https://bugzilla.mozilla.org/show_bug.cgi?id=915312
>>> [3]: https://bugzilla.mozilla.org/show_bug.cgi?id=922887
>>> [4]: https://github.com/lloyd/mehmeh
>>> 
>>> 
>>>> lloyd
>>>> 
>>>>> 
>>>>> Ryan
>>>>> 
>>>>> _______________________________________________
>>>>> Dev-fxacct mailing list
>>>>> Dev-fxacct at mozilla.org
>>>>> https://mail.mozilla.org/listinfo/dev-fxacct
>>>> 
>>>> _______________________________________________
>>>> Dev-fxacct mailing list
>>>> Dev-fxacct at mozilla.org
>>>> https://mail.mozilla.org/listinfo/dev-fxacct
>>> 
>>> _______________________________________________
>>> Dev-fxacct mailing list
>>> Dev-fxacct at mozilla.org
>>> https://mail.mozilla.org/listinfo/dev-fxacct
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/dev-fxacct/attachments/20131106/84962dea/attachment.html>


More information about the Dev-fxacct mailing list