Firefox Accounts: Weak client-side key derivation allows bruteforcing user's password

RESOLVED DUPLICATE of bug 1320222

Status

enhancement
RESOLVED DUPLICATE of bug 1320222
a year ago
25 days ago

People

(Reporter: gaubugzilla, Assigned: rfkelly)

Tracking

unspecified
Points:
---
Bug Flags:
sec-bounty -

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [reporter-external] [web-bounty-form] [verif?])

(Reporter)

Description

a year ago
I realize that this issue is known and has been documented as FXA-01-014 under https://blog.mozilla.org/security/2017/07/18/web-service-audits-firefox-accounts/. However, 18 months after its discovery this issue is still live and I'm unable to even find a bug on it. The only explanation I can see is: the risk has been misjudged considerably here.

In fact, the original report says:

> Further, this attack assumes a very strong malicious adversary who is capable of bypassing TLS

I disagree with that assessment. Bypassing TLS (e.g. by getting a valid certificate for api.accounts.firefox.com and rerouting traffic destined for api.accounts.firefox.com to their own server) is only one way in which this issue could be exploited. The more likely scenario would be compromise of the real api.accounts.firefox.com server:

* By a third-party:
 * Via a vulnerability in the service
 * Via AWS credentials extracted from another compromised service
 * Via AWS credentials extracted from an infected device belonging to a Mozilla administrator
* By an insider:
 * A rogue Mozilla employee
 * A rogue Amazon employee
* By Mozilla, e.g. when facing a subpoena requesting access to data in a particular account

Firefox Sync stores very sensitive data on Mozilla's servers. The promise here is that security of this data doesn't depend on trusting either Mozilla or security of their servers. However, anybody controlling the server can intercept authPW as it comes in. If that token allows to bruteforce user's password with relatively little effort then Firefox Sync doesn't live up to this promise.

The spreadsheet under https://docs.google.com/spreadsheets/d/1iwoMR5TBYAZ5eiSphkIQfIEfbrVvWW_tKwS4L1cYlaI/pubhtml (taken from https://blog.codinghorror.com/hacker-hack-thyself/) provides some benchmarks that can be used as a reference. I divide the numbers by 8 to get the performance of a single Nvidia GTX 1080 GPU: 1,184,150 PBKDF2-HMAC-SHA256 hashes per second (hashcat default is 1000 iterations, which is the same as what Firefox Accounts is currently using). That's fast enough to go through the massive passwords list under https://crackstation.net/buy-crackstation-wordlist-password-cracking-dictionary.htm in merely twenty minutes. And even if the user doesn't reuse passwords and chose a password with 40 bits of entropy (that's a good one, usually it should be less) - five days aren't exactly a long time either. Mind you, we aren't talking about state level adversaries here but about somebody running hashcat on comparably cheap hardware (< $1000).

Mozilla has been citing devices with limited performance as the reason for the weak derivation function here. As it happened, I've run some benchmarks on low-end mobile devices for my PfP: Pain-free Passwords extension. Conclusion: running 100,000 iterations of PBKDF2-HMAC-SHA256 requires less than a second even on mobile devices, so it should be well within the acceptable range. I'd consider that number of iterations the minimum that is still acceptable today, and it happens to be what 1Password and now also LastPass are using. However, given how easy it is to speed up PBKDF2, replacing it by a more resistant algorithm is recommendable. For PfP I chose scrypt(32 * 1024, 8, 1) which performs roughly the same on both desktop and mobile (using a JS-based implementation, https://www.npmjs.com/package/@stablelib/scrypt) while being considerably harder to speed up.
Flags: sec-bounty?
I'm not against revisiting this, but rfkelly is the expert here.
Assignee: nobody → rfkelly
Group: websites-security
Component: Other → Server: Firefox Accounts
Product: Websites → Cloud Services
(Assignee)

Comment 2

a year ago
> I'm unable to even find a bug on it.

Bug 1320222 covers this, but is marked security-sensitive so it's not discoverable by default.  :ulfr what do you think about opening that bug up given all the above public references to the same info?

I believe we're planning some more general work on password strength for Q2 which might be a good opportunity to revisit this.
Flags: needinfo?(jvehent)
I opened bug 1320222
Flags: needinfo?(jvehent)
(Assignee)

Comment 4

a year ago
Thanks, duping to Bug 1320222
Status: NEW → RESOLVED
Last Resolved: a year ago
Resolution: --- → DUPLICATE
Duplicate of bug: 1320222
Flags: sec-bounty? → sec-bounty-
You need to log in before you can comment on or make changes to this bug.