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

Brian Warner warner at
Wed Nov 6 12:21:31 PST 2013

> 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 :).

>> 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.

Simpler: yes. More secure: no. Not less secure: maybe.

The original scope called for a single user password, intended to
provide both proof-of-account-control (the usual requirement) and
server-proof-security (the extra level we need to honor our FF Sync
stance and overall mission). But our ability to hit that second goal
depends upon restricting the use of that one password to specific
places: not passing it over the wire, and ideally not passing it to code
that's come over the wire (protecting ourselves from SSL attacks outside
of the FF upgrade process).

One of the options we rejected was two passwords, because passwords are
horrible and two passwords are worse. But if there's no way to ship an
auth system that's really only used for Sync data and processed by
native code, then it's the next-least-horrible stance to take.

On 11/6/13 11:36 AM, Chris Karlof wrote:
> 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

Incidentally, if we go that way, we should do some more thinking about
SRP. We can't do server-side key-stretching with the SRP verifier, which
means all the protection against compromised servers must come from the
(slow) client, so we can't throw money or Moore's Law at the problem to
keep up with the attackers.

OTOH, the recent revelations make it clear that people are snooping SSL
traffic (by stealing the keys, or plaintext from inside datacenters), so
SRP's defense against passive eavesdropping is still a nice protection
to have.

> 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.


More information about the Dev-fxacct mailing list