bypassing key-stretching (Was Re: 10.21.13 Engineering Progress Report for Firefox Accounts and

Lloyd Hilaiel lhilaiel at
Fri Nov 8 00:56:40 PST 2013

On Nov 6, 2013, at 10:21 PM, Brian Warner <warner at> wrote:

>> On Nov 6, 2013, at 3:57 AM, Lloyd Hilaiel <lhilaiel at
>> <mailto:lhilaiel at>> wrote:
>>> 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.
> Boo scope creep. Even if it's predictable scope creep :).

Scope creep is an indicator that we’re building incredibly important stuff here.  Not boo.  Yay.  And in addition to expanding the scope of Firefox Accounts, we’ve reduced the scope of short term sync work.  

>> 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.
> Yeah, my intention was always to do as much PBKDF as our slowest
> supported clients could do in a reasonable time. If 10k+10k rounds is
> too much, let's explore 5k+5k or even 1k+1k.

To this end, on FxOS in javascript on gecko, we can do 5k rounds in 1 second.  Extrapolating, native would be 4.1x faster [1], that would mean 20k is a reasonable lower bound for native optimized on-device PBDKF2.  I hope that extrapolation is low.

Meta point - it’s a friday hack to determine sign in latency as dictated by our current auth system.  I think we should figure out what we can do on our slowest supported clients (FxOS) soonish, and then set the parameters to address that.  Because we will ship 1.3 with raw password, this doesn’t need to be highest priority.

SRP implies some round trips IIRC, scrypt facilitation sandwiched between local PBKDF2 ALSO implies round trips.  I can tell ya right now 6 round trips and 4s of compute to sign in ain’t gonna cut the mustard.

(now hopefully, I believe we can still have industry leading password handling AND an acceptable UX - but it requires tuning the current security params led by experimentation on fxos)

Alternately, we could do something similar but better than what, last pass does - have a fixed time allocation for PBKDF2 on device, and complete on server.  That would require we ditch SRP IIRC.  tradeoffs abound, eh?


[1] on osx, javascript 250k sha-256 PBKD2 takes 1.67s, native takes .4s.  On device, javascript 250k pbkdf2 takes 47s.  assuming delta between js and native is similar (BIG assumption), you get the 4.1x factor.

> cheers,
> -Brian
> _______________________________________________
> Dev-fxacct mailing list
> Dev-fxacct at

More information about the Dev-fxacct mailing list