Hi, Jörg -
One of the challenges we've always had in prioritizing this work is how
hard it is to evaluate the user risk involved, because the threat model
in this case involves a third party having full access to a target
victim's computer while they're logged in but also choosing not to use
any other, often simpler attack vectors available in that situation.
One of our principal engineers recently made a very similar observation,
when discussing our policies about instrumenting private browsing mode:
"Every scenario we have looked at has been making contrived assumptions
about what the local attacker is willing/able to do (e.g. they have full
access to the user’s computer over an extended period of time, but they
are unable to install any spying software on their machine)."
With that in mind, we've long held the position that the responsibility
for protecting the bytes on the disk from local malfeasance is the
responsibility of the OS via local disk encryption, filesystem
permissions and user authentication, not the browser.
That's not a spectacular argument, but our engineering resources are
finite and in the face of other security issues we definitely need to
manage, like Spectre - which absolutely does have some spectacular
arguments in its corner - that argument has always been enough to move
this bug far enough down the priority list that we never get to it.
Having said that, I'm definitely sympathetic to the position that if
we're offering to encrypt something at all, we shouldn't be using weak
or dated encryption for the job however remote we feel the related risks
are.
We're planning to replace the password manager in Firefox with something
that's much better suited to modernity; better sync, Monitor
integration, even strong-password generation, and - while I don't want
to guarantee anything - I know that solving the encryption-at-rest issue
is on that team's roadmap too. There's a lot going on there, the team
that's working on it is pretty excited about it, and from what I
understand wants to get it out the door well before the end of the year.
Hope that helps.
- mhoye
------ Original Message ------
From: "Jörg Knobloch via governance" <governance@lists.mozilla.org>
To: "Mitchell Baker" <mitch...@mozilla.com>; "governance"
<governance@lists.mozilla.org>
Sent: 2019-04-05 10:02:39 AM
Subject: The master password debacle: What is behind it?
Hi Mitchell,
I am writing to you as a long time Firefox user and Mozilla contributor
for many years.
In the past years we have seen an amazing amount of innovation in
Firefox to make it a faster, more stable, better looking and overall
much better browser. A brilliant team of highly skilled engineers
supported by a dedicated community of volunteers have taken Firefox to
new heights.
That said, fixing a long-standing issue, the highly insecure master
password, has fallen by the wayside. As a brief summary: If the user
chooses, the master password protects site passwords, including access
to webmail, and personal certificates in Firefox. Needless to say that
gaining access to those could have some disastrous consequences. It is
well-known that the master password of Firefox can be cracked in 1-2
minutes with very basic hardware and skill set. The bug is known since
2009[1][2] and Firefox has received bad press about it, some references
here[3][4][5]. I last "poked" the issue here[6] on dev-platform with no
success. Skimming the discussion in the bugs, the consensus appears to
be: Yes it's an issue, yes, it should be fixed, but no action follows.
So I have been wondering what is behind this. Is there a lack of
governance structures within Mozilla or lack of management structures
within the Mozilla Corporation that has not allowed for this issue to
be escalated? It would be hard to believe that Mozilla engineers do not
have the skills to fix what appears to be a very basic problem glancing
at the bugs I quoted. Even if so, an external contractor could be hired
for this task.
Or is this backdoor left open due to some undisclosed obligation? One
could start to believe this when reading the following comment[6, 2nd
in thread]: "Yes, we're looking at it, but don't have a detailed plan
or schedule to share yet". In this case it would be desirable to
officially declare the feature as insecure or even disable it. After
all, the fourth principle of the Mozilla Manifesto reads "Individuals’
security and privacy on the internet are fundamental and must not be
treated as optional".
With kind regards,
Jörg, user and contributor from Berlin, Germany.
[1] https://bugzilla.mozilla.org/show_bug.cgi?id=524403
[2] https://bugzilla.mozilla.org/show_bug.cgi?id=973759
[3]
https://www.bleepingcomputer.com/news/security/firefox-master-password-system-has-been-poorly-secured-for-the-past-9-years/
[4]
https://nakedsecurity.sophos.com/2018/03/20/nine-years-on-firefoxs-master-password-is-still-insecure/
[5]
https://fossbytes.com/firefox-master-password-weak-encryption-brute-force-one-minute/
[6]
https://groups.google.com/d/msg/mozilla.dev.platform/k2g6G2F3xo0/KLICUiJSAQAJ
_______________________________________________
governance mailing list
governance@lists.mozilla.org
https://lists.mozilla.org/listinfo/governance
_______________________________________________
governance mailing list
governance@lists.mozilla.org
https://lists.mozilla.org/listinfo/governance
