info
Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Sync in 2012: Persona Integration
243 views
Skip to first unread message
Gregory Szorc
Apr 11, 2012, 9:25:58 PM4/11/12
to dev-pl...@lists.mozilla.org
tl;dr Drastic changes to Sync have been proposed, including to the
end-to-end security model. A series of posts will detail the main areas
for change and call for feedback to help shape these changes. This
specific post details how the security model of Sync will change to
support integration with Persona.
---
2012 is shaping up to be a significant year for Sync! We have a number
of important decisions to make and would like to collect as much
feedback as possible to help shape the direction of this important feature.
The topic is split into multiple posts to make the discussion easier to
follow. This part focuses on integrating Sync with Persona (Persona is
the Mozilla instance of the BrowserID authentication protocol). But
first, an overview.
Context for Change
==================
The subjects in these posts are driven by a number of factors.
First, we have the user experience of Sync. It's hard to use. User
studies have shown that many people don't grok the Sync setup and
pairing process (especially the latter). This is partially a side-effect
of the original design of Sync, which placed security and user
sovereignty over their data as the main goals (more important than user
experience).
Second, a new "sign in to the browser" feature is on the roadmap [1].
We believe it is in the best interest of the majority of our users to
have Sync "just work" with that. Furthermore, we believe that "sign in
to the browser" without Sync isn't a very compelling feature.
Third, the Services team is working on the next version of the storage
service used by Sync — version 2.0 [2]. This version addresses a number
of deficiencies with the current 1.1 version of the server and is
necessary to provide a better feature.
Fourth, there are a number of warts in Sync's current implementation
that we have been itching to correct. Some of these are backwards
incompatible and so we have been holding off until an opportunity arises
to address them without additional impact.
Persona Integration
===================
The solution we propose to address the user experience deficiencies and
integration with "sign in to the browser" is integration with Persona
(BrowserID). Persona integration will involve two separate, but related
changes: how users authenticate with the Sync server and how the root
Sync encryption key is managed.
Sync Today
==========
To better understand the proposal, it will help to have an understanding
of how Sync works today.
When you initially sign-up for Sync, you create a Mozilla Services
account by specifying an email address and password. We call this
username and password your Sync credentials. All communication with the
Sync server is secured via TLS (HTTPS). All HTTP requests use HTTP Basic
Auth with your Sync credentials to prevent unauthorized access to your
server-stored data. This methodology should be familiar to anyone who
has had experience running an HTTP server.
Now, it gets more complicated.
When you create your Sync account, your machine generates a
cryptographically-secure 128-bit random number. We refer to this 128-bit
random number as your Sync Key.
We use HKDF [3] on your Sync Key to derive two 256-bit keys. One of
these keys is used for symmetric AES-256 encryption; the other for
HMAC-SHA256 message verification. I will spare you from all the
low-level details. Just know that *all* user data is encrypted *locally*
with this key pair (or similar full-entropy 256-bit key pairs) then
uploaded to the Sync server. All encrypted data on the server is chained
to your 128-bit Sync Key. All encrypted data on the server is encrypted
with full-entropy 256-bit keys. Full technical details are available at [4].
Your Sync Key or the derived pair of 256-bit keys is *never* transmitted
to the Sync server or Mozilla (at least in any form they can read — more
later). This means that the Sync server can withstand a full data breach
with only minimal metadata being compromised. The most someone with the
data could ascertain would be modified times, record counts, sizes,
access times, etc. The unencrypted IDs of records on the server are
randomly generated on the client, so even they can't be used to
determine what a specific records corresponds to. Cracking your data
would require a brute-force attack over 128 bits of permutations. This
is statistically impossible.
In short, you need the 128-bit Sync Key to read data stored on the server.
The Sync Key is 128 bits for historical reasons. In the old days of
Sync, people needed to manually type their Sync Key to pair devices. We
use a modified base32 encoding for Sync Key presentation purposes (to
prevent character confusion and so there are no capital characters to
worry about). This requires 26 characters. If we used a 256 bit key,
that would require 52 characters. And, if we wanted a pair of 256 bit
keys, that would require 104 characters! 26 characters was the most we
wanted to ask our users to type, so we have a 128-bit root key.
We thought we could do better on the user experience front, so we
introduced J-PAKE for the pairing setup [5]. With J-PAKE, the user is
presented 12 random characters. These 12 characters (a one-time transfer
code) are entered on another device and the two machines create an
encrypted channel between them (through a central brokering server). The
Sync credentials, Sync Key, and server info are transmitted to the other
client and the new device is paired. Even though data passes through a
central brokering server (which is typically operated by Mozilla), data
is encrypted end-to-end, so even the server can't see what's passing
through. i.e., the Sync Key is not made available to any other party.
With J-PAKE, the user needs to enter only 12 characters instead of 26.
The Sync Key is also hidden from the user (which is good, because we
find that some users do things like email the Sync Key or upload it to
an unencrypted cloud storage service, undermining the security of Sync
in the process). One downside is users need to have simultaneous access
to both devices for the pairing. This isn't always possible. Also,
people are confused by it. They just don't understand what is going on.
Passwords they get. One-time pairing sequences, not so much. Of course,
users still have the option to transpose the key manually (available
behind an advanced settings link).
When we switched to J-PAKE, we could have gotten rid of the 128-bit Sync
Key and replaced it with a pair of 256-bit keys. However, we deemed the
engineering effort was too high to accomodate our schedule at the time.
And, having manual key entry as a fall-back was nice-to-have (for
connecting two devices that aren't both in front of you, for example).
And, a 128-bit key was backwards compatible. And, 128 bits of entropy
for a root key was still pretty good. So, we stuck with a 128-bit Sync
Key with derivation to a pair of 256-bit keys.
Now that you have a basic overview of how Sync works, let's talk about
the proposed changes.
Persona for Authentication
==========================
For Persona integration, we would replace Mozilla Services accounts with
Persona. This means that the Sync server will authenticate clients with
BrowserID assertions, not HTTP Basic Auth with your Mozilla Services
credentials. If you are curious about the implementation details, see [6].
This change would mean that users will need a Persona account to use
Sync. For existing Sync users, we'll likely have some kind of UI in the
browser to prompt you to create a Persona account , possibly with the
same email address used for the Mozilla Services account — we haven't
finalized details yet.
Proposal for Sync Key Management
================================
The larger change for Persona integration would be how your Sync Key is
managed.
First, we propose doing away with the 128-bit Sync Key and HKDF
derivation of a pair of 256-bit keys. Replacing it will be a pair of
randomly-generated 256-bit keys. (We've wanted to do this for a while.)
This effectively increases the maximum achievable cryptographic security
of Sync since we would be using true 256-bit keys rather than those
derived from a 128-bit key. More details are available in part 2 of this
post.
The second change for Persona integration deals with how the Sync Key is
secured and stored. The proposal is for Sync to leverage a "key
wrapping" facility provided by Persona. Full details about Persona key
wrapping are available at [7]. In summary, your Persona account has
associated with it a pair of randomly-generated keys (just like Sync).
This key pair is called the [Persona] User Key, or UK. Persona provides
APIs that can be used to "wrap" and "unwrap" arbitrary pieces of data.
This is just a convenient way of saying that Persona encrypts and signs
(or verifies and decrypts) data with the UK.
When you create a Sync account, the Sync client would generate a random
key (just like today). It would then call a Persona API on the client to
"wrap" your Sync Key. Persona would return a blob of data that is
wrapped/encrypted/signed with the UK. The wrapped Sync Key would then be
uploaded to the Sync server.
When a new Sync client needs to access your data, it would log in to
Persona, fetch the wrapped Sync Key from the Sync server, then hand off
the wrapped data to Persona and get back the original Sync Key. The Sync
client would then proceed like normal. No device pairing. No need to
have two devices in physical proximity. No additional UI. You just log
in to Persona and your Sync-managed data is magically available.
So far, the security model is isomorphic to the world without Persona:
we have keys rooted to a pair of randomly generated 256-bit keys. The
only difference is we have an extra layer of key chaining and the next
link (the Sync Key) is also stored encrypted on the Sync server. No big
deal.
This means we push the problem of managing the root key out of Sync and
into Persona. And management of the Persona UK is where things get
interesting again.
Persona User Key Management
===========================
In order to facilitate Sync "just working" after logging in to Persona,
the UK will need to be stored centrally. If the UK is not stored
centrally nor always available, you are back to Sync's usability issues
around pairing: you'd need some way to transmit the UK between clients.
So, how do we plan to store the UK centrally? The general plan is to
encrypt the UK on the client before it is uploaded to the Persona server
for storage. How, exactly, we're not sure yet.
The minimum proposal is to use PBKDF2 of your Persona login credentials
(i.e., your Persona password) to derive a a password key (PWK). Then,
we'd use the PWK to encrypt and sign the UK before uploading it to the
server. Any client with the Persona credentials could download the
encrypted UK from the Persona server and decrypt it with the PWK. On top
of that, the current proposal is for Mozilla to be the only entity
within the BrowserID ecosystem that stores encrypted UKs. Even IdP's
(which you trust to issue credentials to you) wouldn't have this
information.
When we consider this proposal with Sync, it means that everything would
effectively be chained to a user-supplied password, not a 128-bit Sync Key.
Trying to Appease Everyone
==========================
Usability and security are often at odds with each other and different
people prefer to sit at specific points in this spectrum. No matter what
decision we make, we understand it will be impossible to satisfy
everyone. Even today, with Sync's security model where the server
operators (Mozilla for the default Sync server in Firefox) only have
access to limited metadata (common to just about every hosted service),
there are people who insist on running their own Sync server for privacy
and/or security reasons (see [8] for instructions for running your own
server). There's nothing wrong with doing that or holding that belief.
And, it should not be discouraged.
The general rule is we tailor Firefox to 80% of the users. And today,
80% do not grok Sync's setup process. Since Firefox is expanding to more
mobile devices, where Sync is a must-have feature (for many at least)
and since we wish for people to be able to log in to a "cold" browser
and have access to their data, we need to change Sync so it is usable
without additional setup complexity. This, unfortunately, means reducing
the end-to-end security in the /default/ case.
I want to explicitly state that even though the end-to-end security
would be weakened, it would still be pretty good. We're not talking
about storing your data unencrypted or making your encryption keys
easily available. We feel the end state of this shift is still well
within the acceptable range of most people. Only those in the "more
paranoid" end of the spectrum would "lose coverage."
It would be hard to let these security-minded people go. And, I hope it
doesn't come to that. Above, I mentioned a "default case" for the
security settings. I say "default case" because I (and many others)
insist that users who want to sit at the more secure end of the security
spectrum have that choice, especially since that is where they are now.
I (and many others) believe it would be ethically wrong to ship a
Firefox that permanently eroded Sync's data security protections on
which people have come to rely. To these people who love Sync today
because in a world where your user data is often uploaded unencrypted
and used for behavioral analytics ("you are the product"), Firefox
Sync's model of strong client-side encryption stands out from the crowd
and is rewarded with your patronage: you deserve continued support for
the existing (if not better) level of security.
I (and a lot of other people), are committed to allowing Sync users to
maintain the current level of security while we make the transition to
Persona. I'm not sure exactly how we're going to do that yet. Maybe
there are about:config-only preferences to prevent your Sync Key from
being wrapped with your Persona UK. Maybe Persona has options to control
the minimum encryption levels for the UK. Maybe UK escrow can be
disabled. Maybe we keep the J-PAKE server running and have the Sync
pairing UI somewhere in an advanced settings dialog. Maybe we could use
J-PAKE for the UK. Maybe we require a second set of credentials to
unlock the UK. Maybe accounts have multiple UKs with different security
settings. Maybe we give users the choice between usability and security
when initially configuring Sync or UK management. I don't know yet.
What I can tell you is that a lot of people are thinking about
solutions. And at this point, everything (within reason) is on the table.
We would like to foster a discussion on this subject. If you have any
ideas or opinions, please speak up!
More Secure than PBKDF2
=======================
Above, I mentioned that the current minimum security proposal is for the
Persona UK to be encrypted using a PBKDF2-derived key from your Persona
password. While this is certainly more secure than using no client-side
encryption, it isn't as good as we would like.
A number of people have been losing sleep over how we can do better.
Brian Warner is probably the most sleep-deprived of the lot. His first
proposal is at [9]. If you have an interest in making Persona's key
wrapping facility as secure as possible, please look at his work.
If you are a security or crypto expert, this is a particular area where
your input would be most valuable. Please dump your brain so we can make
the best decision for our users.
Conclusion
==========
Switching Sync to use Persona to support log in to the browser [through
passphrases] — which will enable a better web experience — will involve
weakening Sync's end-to-end security model.
We are looking for input to help minimize the security tradeoff being
made with the transition to better usability. We are also keen to retain
support for the existing level of end-to-end security and would like to
foster a discussion around the best ways to accomplish this.
Happy syncing,
Gregory Szorc
Firefox Sync Engineer
g...@mozilla.com
[1] https://wiki.mozilla.org/Identity/Features/Sign_into_the_browser
[2] http://docs.services.mozilla.com/storage/apis-2.0.html
[3] https://tools.ietf.org/html/rfc5869
[4] http://docs.services.mozilla.com/sync/storageformat5.html
[5] http://docs.services.mozilla.com/keyexchange/index.html
[6] http://docs.services.mozilla.com/token/index.html
[7] https://wiki.mozilla.org/BrowserID_Key_Wrapping
[8] https://docs.services.mozilla.com/
[9] https://wiki.mozilla.org/Identity/CryptoIdeas/01-PBKDF-scrypt
end-to-end security model. A series of posts will detail the main areas
for change and call for feedback to help shape these changes. This
specific post details how the security model of Sync will change to
support integration with Persona.
---
2012 is shaping up to be a significant year for Sync! We have a number
of important decisions to make and would like to collect as much
feedback as possible to help shape the direction of this important feature.
The topic is split into multiple posts to make the discussion easier to
follow. This part focuses on integrating Sync with Persona (Persona is
the Mozilla instance of the BrowserID authentication protocol). But
first, an overview.
Context for Change
==================
The subjects in these posts are driven by a number of factors.
First, we have the user experience of Sync. It's hard to use. User
studies have shown that many people don't grok the Sync setup and
pairing process (especially the latter). This is partially a side-effect
of the original design of Sync, which placed security and user
sovereignty over their data as the main goals (more important than user
experience).
Second, a new "sign in to the browser" feature is on the roadmap [1].
We believe it is in the best interest of the majority of our users to
have Sync "just work" with that. Furthermore, we believe that "sign in
to the browser" without Sync isn't a very compelling feature.
Third, the Services team is working on the next version of the storage
service used by Sync — version 2.0 [2]. This version addresses a number
of deficiencies with the current 1.1 version of the server and is
necessary to provide a better feature.
Fourth, there are a number of warts in Sync's current implementation
that we have been itching to correct. Some of these are backwards
incompatible and so we have been holding off until an opportunity arises
to address them without additional impact.
Persona Integration
===================
The solution we propose to address the user experience deficiencies and
integration with "sign in to the browser" is integration with Persona
(BrowserID). Persona integration will involve two separate, but related
changes: how users authenticate with the Sync server and how the root
Sync encryption key is managed.
Sync Today
==========
To better understand the proposal, it will help to have an understanding
of how Sync works today.
When you initially sign-up for Sync, you create a Mozilla Services
account by specifying an email address and password. We call this
username and password your Sync credentials. All communication with the
Sync server is secured via TLS (HTTPS). All HTTP requests use HTTP Basic
Auth with your Sync credentials to prevent unauthorized access to your
server-stored data. This methodology should be familiar to anyone who
has had experience running an HTTP server.
Now, it gets more complicated.
When you create your Sync account, your machine generates a
cryptographically-secure 128-bit random number. We refer to this 128-bit
random number as your Sync Key.
We use HKDF [3] on your Sync Key to derive two 256-bit keys. One of
these keys is used for symmetric AES-256 encryption; the other for
HMAC-SHA256 message verification. I will spare you from all the
low-level details. Just know that *all* user data is encrypted *locally*
with this key pair (or similar full-entropy 256-bit key pairs) then
uploaded to the Sync server. All encrypted data on the server is chained
to your 128-bit Sync Key. All encrypted data on the server is encrypted
with full-entropy 256-bit keys. Full technical details are available at [4].
Your Sync Key or the derived pair of 256-bit keys is *never* transmitted
to the Sync server or Mozilla (at least in any form they can read — more
later). This means that the Sync server can withstand a full data breach
with only minimal metadata being compromised. The most someone with the
data could ascertain would be modified times, record counts, sizes,
access times, etc. The unencrypted IDs of records on the server are
randomly generated on the client, so even they can't be used to
determine what a specific records corresponds to. Cracking your data
would require a brute-force attack over 128 bits of permutations. This
is statistically impossible.
In short, you need the 128-bit Sync Key to read data stored on the server.
The Sync Key is 128 bits for historical reasons. In the old days of
Sync, people needed to manually type their Sync Key to pair devices. We
use a modified base32 encoding for Sync Key presentation purposes (to
prevent character confusion and so there are no capital characters to
worry about). This requires 26 characters. If we used a 256 bit key,
that would require 52 characters. And, if we wanted a pair of 256 bit
keys, that would require 104 characters! 26 characters was the most we
wanted to ask our users to type, so we have a 128-bit root key.
We thought we could do better on the user experience front, so we
introduced J-PAKE for the pairing setup [5]. With J-PAKE, the user is
presented 12 random characters. These 12 characters (a one-time transfer
code) are entered on another device and the two machines create an
encrypted channel between them (through a central brokering server). The
Sync credentials, Sync Key, and server info are transmitted to the other
client and the new device is paired. Even though data passes through a
central brokering server (which is typically operated by Mozilla), data
is encrypted end-to-end, so even the server can't see what's passing
through. i.e., the Sync Key is not made available to any other party.
With J-PAKE, the user needs to enter only 12 characters instead of 26.
The Sync Key is also hidden from the user (which is good, because we
find that some users do things like email the Sync Key or upload it to
an unencrypted cloud storage service, undermining the security of Sync
in the process). One downside is users need to have simultaneous access
to both devices for the pairing. This isn't always possible. Also,
people are confused by it. They just don't understand what is going on.
Passwords they get. One-time pairing sequences, not so much. Of course,
users still have the option to transpose the key manually (available
behind an advanced settings link).
When we switched to J-PAKE, we could have gotten rid of the 128-bit Sync
Key and replaced it with a pair of 256-bit keys. However, we deemed the
engineering effort was too high to accomodate our schedule at the time.
And, having manual key entry as a fall-back was nice-to-have (for
connecting two devices that aren't both in front of you, for example).
And, a 128-bit key was backwards compatible. And, 128 bits of entropy
for a root key was still pretty good. So, we stuck with a 128-bit Sync
Key with derivation to a pair of 256-bit keys.
Now that you have a basic overview of how Sync works, let's talk about
the proposed changes.
Persona for Authentication
==========================
For Persona integration, we would replace Mozilla Services accounts with
Persona. This means that the Sync server will authenticate clients with
BrowserID assertions, not HTTP Basic Auth with your Mozilla Services
credentials. If you are curious about the implementation details, see [6].
This change would mean that users will need a Persona account to use
Sync. For existing Sync users, we'll likely have some kind of UI in the
browser to prompt you to create a Persona account , possibly with the
same email address used for the Mozilla Services account — we haven't
finalized details yet.
Proposal for Sync Key Management
================================
The larger change for Persona integration would be how your Sync Key is
managed.
First, we propose doing away with the 128-bit Sync Key and HKDF
derivation of a pair of 256-bit keys. Replacing it will be a pair of
randomly-generated 256-bit keys. (We've wanted to do this for a while.)
This effectively increases the maximum achievable cryptographic security
of Sync since we would be using true 256-bit keys rather than those
derived from a 128-bit key. More details are available in part 2 of this
post.
The second change for Persona integration deals with how the Sync Key is
secured and stored. The proposal is for Sync to leverage a "key
wrapping" facility provided by Persona. Full details about Persona key
wrapping are available at [7]. In summary, your Persona account has
associated with it a pair of randomly-generated keys (just like Sync).
This key pair is called the [Persona] User Key, or UK. Persona provides
APIs that can be used to "wrap" and "unwrap" arbitrary pieces of data.
This is just a convenient way of saying that Persona encrypts and signs
(or verifies and decrypts) data with the UK.
When you create a Sync account, the Sync client would generate a random
key (just like today). It would then call a Persona API on the client to
"wrap" your Sync Key. Persona would return a blob of data that is
wrapped/encrypted/signed with the UK. The wrapped Sync Key would then be
uploaded to the Sync server.
When a new Sync client needs to access your data, it would log in to
Persona, fetch the wrapped Sync Key from the Sync server, then hand off
the wrapped data to Persona and get back the original Sync Key. The Sync
client would then proceed like normal. No device pairing. No need to
have two devices in physical proximity. No additional UI. You just log
in to Persona and your Sync-managed data is magically available.
So far, the security model is isomorphic to the world without Persona:
we have keys rooted to a pair of randomly generated 256-bit keys. The
only difference is we have an extra layer of key chaining and the next
link (the Sync Key) is also stored encrypted on the Sync server. No big
deal.
This means we push the problem of managing the root key out of Sync and
into Persona. And management of the Persona UK is where things get
interesting again.
Persona User Key Management
===========================
In order to facilitate Sync "just working" after logging in to Persona,
the UK will need to be stored centrally. If the UK is not stored
centrally nor always available, you are back to Sync's usability issues
around pairing: you'd need some way to transmit the UK between clients.
So, how do we plan to store the UK centrally? The general plan is to
encrypt the UK on the client before it is uploaded to the Persona server
for storage. How, exactly, we're not sure yet.
The minimum proposal is to use PBKDF2 of your Persona login credentials
(i.e., your Persona password) to derive a a password key (PWK). Then,
we'd use the PWK to encrypt and sign the UK before uploading it to the
server. Any client with the Persona credentials could download the
encrypted UK from the Persona server and decrypt it with the PWK. On top
of that, the current proposal is for Mozilla to be the only entity
within the BrowserID ecosystem that stores encrypted UKs. Even IdP's
(which you trust to issue credentials to you) wouldn't have this
information.
When we consider this proposal with Sync, it means that everything would
effectively be chained to a user-supplied password, not a 128-bit Sync Key.
Trying to Appease Everyone
==========================
Usability and security are often at odds with each other and different
people prefer to sit at specific points in this spectrum. No matter what
decision we make, we understand it will be impossible to satisfy
everyone. Even today, with Sync's security model where the server
operators (Mozilla for the default Sync server in Firefox) only have
access to limited metadata (common to just about every hosted service),
there are people who insist on running their own Sync server for privacy
and/or security reasons (see [8] for instructions for running your own
server). There's nothing wrong with doing that or holding that belief.
And, it should not be discouraged.
The general rule is we tailor Firefox to 80% of the users. And today,
80% do not grok Sync's setup process. Since Firefox is expanding to more
mobile devices, where Sync is a must-have feature (for many at least)
and since we wish for people to be able to log in to a "cold" browser
and have access to their data, we need to change Sync so it is usable
without additional setup complexity. This, unfortunately, means reducing
the end-to-end security in the /default/ case.
I want to explicitly state that even though the end-to-end security
would be weakened, it would still be pretty good. We're not talking
about storing your data unencrypted or making your encryption keys
easily available. We feel the end state of this shift is still well
within the acceptable range of most people. Only those in the "more
paranoid" end of the spectrum would "lose coverage."
It would be hard to let these security-minded people go. And, I hope it
doesn't come to that. Above, I mentioned a "default case" for the
security settings. I say "default case" because I (and many others)
insist that users who want to sit at the more secure end of the security
spectrum have that choice, especially since that is where they are now.
I (and many others) believe it would be ethically wrong to ship a
Firefox that permanently eroded Sync's data security protections on
which people have come to rely. To these people who love Sync today
because in a world where your user data is often uploaded unencrypted
and used for behavioral analytics ("you are the product"), Firefox
Sync's model of strong client-side encryption stands out from the crowd
and is rewarded with your patronage: you deserve continued support for
the existing (if not better) level of security.
I (and a lot of other people), are committed to allowing Sync users to
maintain the current level of security while we make the transition to
Persona. I'm not sure exactly how we're going to do that yet. Maybe
there are about:config-only preferences to prevent your Sync Key from
being wrapped with your Persona UK. Maybe Persona has options to control
the minimum encryption levels for the UK. Maybe UK escrow can be
disabled. Maybe we keep the J-PAKE server running and have the Sync
pairing UI somewhere in an advanced settings dialog. Maybe we could use
J-PAKE for the UK. Maybe we require a second set of credentials to
unlock the UK. Maybe accounts have multiple UKs with different security
settings. Maybe we give users the choice between usability and security
when initially configuring Sync or UK management. I don't know yet.
What I can tell you is that a lot of people are thinking about
solutions. And at this point, everything (within reason) is on the table.
We would like to foster a discussion on this subject. If you have any
ideas or opinions, please speak up!
More Secure than PBKDF2
=======================
Above, I mentioned that the current minimum security proposal is for the
Persona UK to be encrypted using a PBKDF2-derived key from your Persona
password. While this is certainly more secure than using no client-side
encryption, it isn't as good as we would like.
A number of people have been losing sleep over how we can do better.
Brian Warner is probably the most sleep-deprived of the lot. His first
proposal is at [9]. If you have an interest in making Persona's key
wrapping facility as secure as possible, please look at his work.
If you are a security or crypto expert, this is a particular area where
your input would be most valuable. Please dump your brain so we can make
the best decision for our users.
Conclusion
==========
Switching Sync to use Persona to support log in to the browser [through
passphrases] — which will enable a better web experience — will involve
weakening Sync's end-to-end security model.
We are looking for input to help minimize the security tradeoff being
made with the transition to better usability. We are also keen to retain
support for the existing level of end-to-end security and would like to
foster a discussion around the best ways to accomplish this.
Happy syncing,
Gregory Szorc
Firefox Sync Engineer
g...@mozilla.com
[1] https://wiki.mozilla.org/Identity/Features/Sign_into_the_browser
[2] http://docs.services.mozilla.com/storage/apis-2.0.html
[3] https://tools.ietf.org/html/rfc5869
[4] http://docs.services.mozilla.com/sync/storageformat5.html
[5] http://docs.services.mozilla.com/keyexchange/index.html
[6] http://docs.services.mozilla.com/token/index.html
[7] https://wiki.mozilla.org/BrowserID_Key_Wrapping
[8] https://docs.services.mozilla.com/
[9] https://wiki.mozilla.org/Identity/CryptoIdeas/01-PBKDF-scrypt
Jens Hatlak
Apr 12, 2012, 2:09:01 AM4/12/12
to
Gregory Szorc wrote:
> On top of that, the current proposal is for Mozilla to be the only
> entity within the BrowserID ecosystem that stores encrypted UKs. Even
> IdP's (which you trust to issue credentials to you) wouldn't have
> this information.
Which would basically mean that concerned users would not have the
> On top of that, the current proposal is for Mozilla to be the only
> entity within the BrowserID ecosystem that stores encrypted UKs. Even
> IdP's (which you trust to issue credentials to you) wouldn't have
> this information.
option to run their own Sync server environment anymore, right? I guess
you know that (I did acknowledge all the concerns at the end of your
mail), but I just wanted to highlight that part. People have different
reasons to run their own server, and it's not necessarily only paranoid
people (lack of trust in Mozilla or anyone else), but also people who
don't want to depend on the (network) availability of third-party
servers (more control). I'm pretty sure that in reality this is a tiny
fraction of users, but still.
> When we consider this proposal with Sync, it means that everything
> would effectively be chained to a user-supplied password, not a
> 128-bit Sync Key.
all means/practically) secure to something that is:
* user-supplied (I didn't check the BrowserID setup, but I doubt you
force users to choose their master password from a list of secure
alternatives)
* possibly used elsewhere (commonly observed among ordinary users; could
in theory also apply to the current setup but I think it's much more
unlikely that people use the Sync Key for something else)
So if you did that, you'd have to ensure that the BrowserID master
password itself is secure and unlikely to be used for other services.
Requiring it to be (more) secure would probably imply making it much
harder to remember (possible alternative: actual passphrase, possibly
consisting of multiple words), which would hurt your other requirement:
Ease of use (which I think better describes what you aim at than
"Usability", but maybe that's just me).
Again, I don't know how BrowserID works today, whether insecure master
passwords are permitted or not (a password strength meter as an
indicator for example alone doesn't really enhance security, only
requiring a certain level does). But I feel that if in the future Sync's
security comes down to a password, we're back at square one, forcing the
user to remember a secure password (whether they'll be forced to pick
it, too, is mostly irrelevant here). And we all know that in reality
that just doesn't work.
So, what else can we do? Obviously, what we currently have is better
security-wise but not considered easy enough to use for average users.
As a trade-off between ease of use and security, if the BrowserID master
password's security cannot be guaranteed/enhanced, maybe we need an
extra Sync setup password/passphrase. One that cannot be chosen by the
user (i.e. always generated), with a certain defined strength (not
cryptographically secure but better than user-supplied), to be used in
connection with the BrowserID master password, but only for Sync setup
purposes. Something like a PIN (well, maybe a bit better). [I'm not
saying this is the solution, just thinking.]
Greetings,
Jens
(SeaMonkey Sync owner)
--
Jens Hatlak <http://jens.hatlak.de/>
SeaMonkey Trunk Tracker <http://smtt.blogspot.com/>
Justin Lebar
Apr 12, 2012, 2:44:00 AM4/12/12
to Gregory Szorc, dev-pl...@lists.mozilla.org
Two separate points here.
***
> [9] https://wiki.mozilla.org/Identity/CryptoIdeas/01-PBKDF-scrypt
To comment on this analysis: I don't think "passwords have X bits of
entryopy" captures the whole situation here.
Some users choose weak passwords, while others choose strong
passwords. The relevant question isn't "how many iterations does it
take in order to brute-force one key, on average", but rather "how
many iterations does it take to brute-force the Y easiest keys out of
the corpus I managed to acquire, for some distribution of key
strengths D?"
I'd be curious to see the analysis from [9] applied to this
alternative question. I'd expect the conclusions would be quite
different! It seems to me that the proposal here is to move from a
system which is secure by default to a system which is secure if you
choose a moderately good password. Maybe that's OK, but I don't think
that point is emphasized in [9].
***
Separately, have you guys considered using sign-in to the browser to
facilitate a JPAKE key exchange? I log in to my phone's browser and
click sync. It immediately pops up a dialog on my desktop browser,
and I type into my phone the key shown there (or vice versa). You
still have the problem of "how do I set up sync when I'm not at my
desktop?", of course, but this would be a huge improvement over the
current flow.
-Justin
> the Persona server and decrypt it with the PWK. On top of that, the current
> _______________________________________________
> dev-planning mailing list
> dev-pl...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-planning
***
> [9] https://wiki.mozilla.org/Identity/CryptoIdeas/01-PBKDF-scrypt
To comment on this analysis: I don't think "passwords have X bits of
entryopy" captures the whole situation here.
Some users choose weak passwords, while others choose strong
passwords. The relevant question isn't "how many iterations does it
take in order to brute-force one key, on average", but rather "how
many iterations does it take to brute-force the Y easiest keys out of
the corpus I managed to acquire, for some distribution of key
strengths D?"
I'd be curious to see the analysis from [9] applied to this
alternative question. I'd expect the conclusions would be quite
different! It seems to me that the proposal here is to move from a
system which is secure by default to a system which is secure if you
choose a moderately good password. Maybe that's OK, but I don't think
that point is emphasized in [9].
***
Separately, have you guys considered using sign-in to the browser to
facilitate a JPAKE key exchange? I log in to my phone's browser and
click sync. It immediately pops up a dialog on my desktop browser,
and I type into my phone the key shown there (or vice versa). You
still have the problem of "how do I set up sync when I'm not at my
desktop?", of course, but this would be a huge improvement over the
current flow.
-Justin
> proposal is for Mozilla to be the only entity within the BrowserID ecosystem
> that stores encrypted UKs. Even IdP's (which you trust to issue credentials
> to you) wouldn't have this information.
>
> that stores encrypted UKs. Even IdP's (which you trust to issue credentials
> to you) wouldn't have this information.
>
> When we consider this proposal with Sync, it means that everything would
> effectively be chained to a user-supplied password, not a 128-bit Sync Key.
>
> effectively be chained to a user-supplied password, not a 128-bit Sync Key.
>
> dev-planning mailing list
> dev-pl...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-planning
Gregory Szorc
Apr 12, 2012, 3:14:43 AM4/12/12
to Justin Lebar, dev-pl...@lists.mozilla.org
On 4/11/12 11:44 PM, Justin Lebar wrote:
> Separately, have you guys considered using sign-in to the browser to
> facilitate a JPAKE key exchange? I log in to my phone's browser and
> click sync. It immediately pops up a dialog on my desktop browser,
> and I type into my phone the key shown there (or vice versa). You
> still have the problem of "how do I set up sync when I'm not at my
> desktop?", of course, but this would be a huge improvement over the
> current flow.
There are many interesting possibilities here. Some people have
> Separately, have you guys considered using sign-in to the browser to
> facilitate a JPAKE key exchange? I log in to my phone's browser and
> click sync. It immediately pops up a dialog on my desktop browser,
> and I type into my phone the key shown there (or vice versa). You
> still have the problem of "how do I set up sync when I'm not at my
> desktop?", of course, but this would be a huge improvement over the
> current flow.
suggested *temporarily* uploading keys to a central server. Perhaps they
are protected with your credentials plus a 4 digit pin or other "weak"
password. If you don't pull them down in a few hours, they are lost.
That reduces the window that a remote entity can obtain a copy for
offline brute-force attack.
For your specific suggestion, we currently have a tech problem for
"immediately" opening a dialog on the other device. Browser
notifications could potentially provide a solution here. A "command" API
on top of Persona could also be built. There are many possibilities.
Keep em coming!
Millwood
Apr 12, 2012, 9:29:29 AM4/12/12
to
Case 1: You get a new device and want to attach to sync without access
to an already registered device. In this case, the connect must be
based on something you know (or something you have). Thus a password.
But note that this happens maybe once a year if you are a phone junkie.
So it better be a password you use all the time for something else!
People would probably use their email password. And that leaves the
persona store vulnerable to all sorts of attacks.
Case 2: You have the new device and an existing device. In that case,
I'm trying hard to see what's wrong with the current scheme except that
the human factors of the screens are not well enough thought out. But
it's also likely that a much weaker authentication would do if it were
temporary. Like a pop up on the registered browser asking permission to
connect the new device with some simple identification of the new
device, similar to bluetooth pairing.
Also note that once we are into mobile devices, loss/theft of an already
registered device becomes a risk which may dwarf the issues being
considered here. So a way to shut down access after loss/theft should
also be designed.
Finally - give me a choice in this, whatever you do.
Daniel Cater
Apr 12, 2012, 12:49:40 PM4/12/12
to mozilla.de...@googlegroups.com, dev-pl...@lists.mozilla.org
2-factor authentication? Google has it, Facebook has it. I use it on both of them and find it very reassuring when entering my username and password on a new device. I prefer the Google Authenticator approach as it works even if I have no signal on my phone, unlike the Facebook text message approach.
I certainly wouldn't be happy knowing that my Sync storage was ultimately protected by a username and password. However, with the current setup, I would think many people have their Sync key printed out and stored somewhere (there's a nice Print button in the key dialogue after all) which isn't great either.
I initially set up Sync on my desktop and have since added 2 other desktops at other locations and my laptop. Only with the laptop did I use J-PAKE. With the others, I had to carry the key around with me. I actually did this by taking a photo of it with my phone. It happens to have an encrypted SD card and a screen lock, but most people would probably just print it out.
I certainly wouldn't be happy knowing that my Sync storage was ultimately protected by a username and password. However, with the current setup, I would think many people have their Sync key printed out and stored somewhere (there's a nice Print button in the key dialogue after all) which isn't great either.
I initially set up Sync on my desktop and have since added 2 other desktops at other locations and my laptop. Only with the laptop did I use J-PAKE. With the others, I had to carry the key around with me. I actually did this by taking a photo of it with my phone. It happens to have an encrypted SD card and a screen lock, but most people would probably just print it out.
Daniel Cater
Apr 12, 2012, 12:49:40 PM4/12/12
to dev-pl...@lists.mozilla.org
Yvan Boily
Apr 12, 2012, 1:26:41 PM4/12/12
to dev-pl...@lists.mozilla.org
TL;DR: 2FA mitigates some of the risk of an attacker compromising a sync
account, but does nothing to improve the encryption scheme that is based
on a password-based encryption key. That said, I think we should move
to support 2FA via HOTP/TOTP for compatibility with tools like Google
Authenticator regardless of how Sync shapes up.
---
While 2-factor authentication will improve the security of an account
for the purposes of authentication, it does little to improve the
security of an encryption scheme where the security depends on the
strength of the encryption key.
Generalizing the flow of authenticating with BrowserID to recover the
user key, assuming that we are using PBKDF2 or a comparable scheme that
converts the password into an encryption key, we get:
1. User initiates authentication, supplying username and password
2. The user account is looked up, and 2-factor authentication is
required [1]
3. The user is receives the 2-factor auth challenge
4. Upon submitting the challenge, the username and password
authentication step is completed [2]
5. The PBKDF2 function is executed, and the PWK is used to decrypt the UK.
Multi-factor authentication improves the security of an account against
online attackers, but someone who has access to Persona user database
(or at least the column storing the UK encrypted by the PWK) will still
be able to attempt an offline attack to recover the UK.
[1] While this could theoretically allow user account enumeration, that
is already possible by attempting to enroll a new Persona account; this
step fails if a user account already exists.
[2] password authentication should not happen until after the 2FA
challenge is successful; this ensures that an attacker can't use the 2fa
challenge as an oracle for a successful password check. This is not a
serious issue if there are mitigating controls, such as temporary
account lockouts after a specific number of authentication attempts.
account, but does nothing to improve the encryption scheme that is based
on a password-based encryption key. That said, I think we should move
to support 2FA via HOTP/TOTP for compatibility with tools like Google
Authenticator regardless of how Sync shapes up.
---
While 2-factor authentication will improve the security of an account
for the purposes of authentication, it does little to improve the
security of an encryption scheme where the security depends on the
strength of the encryption key.
Generalizing the flow of authenticating with BrowserID to recover the
user key, assuming that we are using PBKDF2 or a comparable scheme that
converts the password into an encryption key, we get:
1. User initiates authentication, supplying username and password
2. The user account is looked up, and 2-factor authentication is
required [1]
3. The user is receives the 2-factor auth challenge
4. Upon submitting the challenge, the username and password
authentication step is completed [2]
5. The PBKDF2 function is executed, and the PWK is used to decrypt the UK.
Multi-factor authentication improves the security of an account against
online attackers, but someone who has access to Persona user database
(or at least the column storing the UK encrypted by the PWK) will still
be able to attempt an offline attack to recover the UK.
[1] While this could theoretically allow user account enumeration, that
is already possible by attempting to enroll a new Persona account; this
step fails if a user account already exists.
[2] password authentication should not happen until after the 2FA
challenge is successful; this ensures that an attacker can't use the 2fa
challenge as an oracle for a successful password check. This is not a
serious issue if there are mitigating controls, such as temporary
account lockouts after a specific number of authentication attempts.
Matrus
Apr 12, 2012, 1:28:03 PM4/12/12
to dev-pl...@lists.mozilla.org
On Thursday, April 12, 2012 6:49:40 PM UTC+2, Daniel Cater wrote:
> However, with the current setup, I would think many people have their Sync key printed out and stored somewhere (there's a nice Print button in the key dialogue after all) which isn't great either.
I regard physical access to a print-out a far higher barrier than storing the key on devices which are connected to the Internet which always are in danger of being compromised anonymously. This is especially bad when the servers are affected as this potentially affects all users and not just a single device. The current sync design makes this a non-issue as far as I understand it because Mozilla does not possess the means to decrypt the user data.
> However, with the current setup, I would think many people have their Sync key printed out and stored somewhere (there's a nice Print button in the key dialogue after all) which isn't great either.
If Mozilla is intending to offer a similar feature to Chrome's sign-in why not carbon copy their setup by including the option to use a separate sync key? Existing users would be migrated to this option without loss of security or privacy while new users can use their password as means to access their data.
Gregory Szorc
Apr 12, 2012, 1:48:04 PM4/12/12
to Jens Hatlak
On 4/11/12 11:09 PM, Jens Hatlak wrote:
> Gregory Szorc wrote:
>> On top of that, the current proposal is for Mozilla to be the only
>> entity within the BrowserID ecosystem that stores encrypted UKs. Even
>> IdP's (which you trust to issue credentials to you) wouldn't have
>> this information.
>
> Which would basically mean that concerned users would not have the
> option to run their own Sync server environment anymore, right? I guess
> you know that (I did acknowledge all the concerns at the end of your
> mail), but I just wanted to highlight that part. People have different
> reasons to run their own server, and it's not necessarily only paranoid
> people (lack of trust in Mozilla or anyone else), but also people who
> don't want to depend on the (network) availability of third-party
> servers (more control). I'm pretty sure that in reality this is a tiny
> fraction of users, but still.
We will support people running their own Sync server: we just don't know
> Gregory Szorc wrote:
>> On top of that, the current proposal is for Mozilla to be the only
>> entity within the BrowserID ecosystem that stores encrypted UKs. Even
>> IdP's (which you trust to issue credentials to you) wouldn't have
>> this information.
>
> Which would basically mean that concerned users would not have the
> option to run their own Sync server environment anymore, right? I guess
> you know that (I did acknowledge all the concerns at the end of your
> mail), but I just wanted to highlight that part. People have different
> reasons to run their own server, and it's not necessarily only paranoid
> people (lack of trust in Mozilla or anyone else), but also people who
> don't want to depend on the (network) availability of third-party
> servers (more control). I'm pretty sure that in reality this is a tiny
> fraction of users, but still.
what the client-side configuration will look like yet.
I'm writing the changes for Firefox Sync and I am purposefully making
the auth/key bits pluggable. Worst case you will need to install an
extension that monkeypatches a few well-documented JS functions. I would
prefer we ship something in the browser itself.
Toby Elliott
Apr 12, 2012, 2:02:13 PM4/12/12
to
can still install your own sync server. Ideally, you'll be able to
configure it to use browserid.org as your RP for authentication, or
you'll be able to set up your own primary and configure to auth just
against that, and it should all just work.
Giving the users the ability to do this if they wish is important to
us, and has been a requirement from the start.
Toby
Brian Warner
Apr 12, 2012, 3:16:24 PM4/12/12
to dev-pl...@lists.mozilla.org, Justin Lebar
On 4/11/12 11:44 PM, Justin Lebar wrote:
>> [9] https://wiki.mozilla.org/Identity/CryptoIdeas/01-PBKDF-scrypt
>
> To comment on this analysis: I don't think "passwords have X bits of
> entropy" captures the whole situation here.
>
> To comment on this analysis: I don't think "passwords have X bits of
>
> Some users choose weak passwords, while others choose strong
> passwords. The relevant question isn't "how many iterations does it
> take in order to brute-force one key, on average", but rather "how
> many iterations does it take to brute-force the Y easiest keys out of
> the corpus I managed to acquire, for some distribution of key
> strengths D?"
Hi, Brian here, I'm the one who wrote up that 01-PBKDF-scrypt idea last
> Some users choose weak passwords, while others choose strong
> passwords. The relevant question isn't "how many iterations does it
> take in order to brute-force one key, on average", but rather "how
> many iterations does it take to brute-force the Y easiest keys out of
> the corpus I managed to acquire, for some distribution of key
> strengths D?"
week.
I should have mentioned in that diagram that the server-side data
(available to an admin or attacker) is salted with each user's account
identifier, i.e. the BrowserID email address attached to that wrapped
key. So you'd have to attack each key separately.
If I understand your question correctly, you're talking about searching
the keys along the other axis. Imagine a rectangle, and the N user
accounts are along the top side, while passwords (from most-likely to
least-likely) are along the left side.
If you have a specific (high-value) target in mind, you'll walk the
rectangle down-then-across, spending some amount of time on a single
user before giving up and finding someone easier. That per-user cost
function is what I wrote up last week.
But you might walk the rectangle across-then-down: spending N queries to
see if anyone has the first easy password, then another N queries to
check if anyone has the next-least-easy password, etc. That's an
interesting question! I'll have to think about it more.
At first glance.. let's see, I estimated my 1s-scrypt-based function as
costing the attacker 7.5 microbucks per query, so $258k for a 35-bit
password. To test across-then-down, you have to pay N times as much for
each guess. If we say the server holds 1M records, then you pay $7.5 per
query. With a budget of $7680, you can test 2^10 passwords. $8M lets you
test 2^20 passwords.
If we let folks pick their own (weak) passwords, I'm sure you could come
up with a list of 1024 likely ones that would capture some fraction of
1M users. (we may not let them do that.. I'm prototyping an XKCD-style
word-generator to do UX testing on which would get more like 35 bits of
entropy). Is that fraction worth $7680 of attacker CPU time? I don't
know how to answer that, but it feels unlikely.
> It seems to me that the proposal here is to move from a system which
> is secure by default to a system which is secure if you choose a
> moderately good password. Maybe that's OK, but I don't think that
> point is emphasized in [9].
it was out-of-scope.. [9] presumes that we've already switched to a
cold-start-enabled system, and just seeks to make such a system as
secure as possible given the cold-start constraint.
thanks!
-Brian
Justin Lebar
Apr 12, 2012, 3:45:04 PM4/12/12
to Brian Warner, dev-pl...@lists.mozilla.org
> If I understand your question correctly [snip]
You do.
> If we let folks pick their own (weak) passwords, I'm sure you could come
> up with a list of 1024 likely ones that would capture some fraction of
> 1M users. (we may not let them do that.. I'm prototyping an XKCD-style
> word-generator to do UX testing on which would get more like 35 bits of
> entropy). Is that fraction worth $7680 of attacker CPU time? I don't
> know how to answer that, but it feels unlikely.
I don't think my browsing history is particularly valuable. But my
login credentials?
Suppose our estimates are a bit high (I'm an unscrupulous hacker, so
I'm not above using CPU time I didn't entirely pay for), and it's
actually $1000 of CPU time.
How much is one webmail password worth? $0.25 doesn't seem ridiculous
(this paper [1] helpfully says $0.10 - $100, as though I'm supposed to
believe a four-order-of-magnitude range).
At that price, to recoup my investment, I need to get a webmail
password from 0.4% of the 1M accounts I compromised. This seems quite
feasible to me!
And of course we don't need to stop with webmail. Surely a non-zero
fraction of people use the same password for their bank and another
site, so even if the bank doesn't let them save their password,
they're still owned. Bank account credentials are, according to the
same report, worth $10 - $1000 a pop.
We can quibble over the details, but the analysis holds only if it's
patently unprofitable for anyone to try to run this kind of attack. I
don't think it is.
[1] http://eval.symantec.com/mktginfo/enterprise/white_papers/b-whitepaper_exec_summary_internet_security_threat_report_xiv_04-2009.en-us.pdf
You do.
> If we let folks pick their own (weak) passwords, I'm sure you could come
> up with a list of 1024 likely ones that would capture some fraction of
> 1M users. (we may not let them do that.. I'm prototyping an XKCD-style
> word-generator to do UX testing on which would get more like 35 bits of
> entropy). Is that fraction worth $7680 of attacker CPU time? I don't
> know how to answer that, but it feels unlikely.
login credentials?
Suppose our estimates are a bit high (I'm an unscrupulous hacker, so
I'm not above using CPU time I didn't entirely pay for), and it's
actually $1000 of CPU time.
How much is one webmail password worth? $0.25 doesn't seem ridiculous
(this paper [1] helpfully says $0.10 - $100, as though I'm supposed to
believe a four-order-of-magnitude range).
At that price, to recoup my investment, I need to get a webmail
password from 0.4% of the 1M accounts I compromised. This seems quite
feasible to me!
And of course we don't need to stop with webmail. Surely a non-zero
fraction of people use the same password for their bank and another
site, so even if the bank doesn't let them save their password,
they're still owned. Bank account credentials are, according to the
same report, worth $10 - $1000 a pop.
We can quibble over the details, but the analysis holds only if it's
patently unprofitable for anyone to try to run this kind of attack. I
don't think it is.
[1] http://eval.symantec.com/mktginfo/enterprise/white_papers/b-whitepaper_exec_summary_internet_security_threat_report_xiv_04-2009.en-us.pdf
Ben Adida
Apr 12, 2012, 8:05:14 PM4/12/12
to
On 4/11/12 6:25 PM, Gregory Szorc wrote:
> tl;dr Drastic changes to Sync have been proposed, including to the
> end-to-end security model.
I want to add a bit of color to the data security discussion. Here's a
> tl;dr Drastic changes to Sync have been proposed, including to the
> end-to-end security model.
presentation I gave a few weeks ago on this topic:
http://vid.ly/5x1u5r
Many (most?) users expect to be able to recover their data with only
their username/password. How might we enable that? For deep technical
reasons, we can't with the current product.
Unfortunately, crypto isn't magic [1] and can't solve this for us
without some amount of compromise. So the question is, how can we make
it as secure as possible?
Persona-based Signin-to-the-Browser using key-wrapping, described in the
talk and a bit more on the wiki [2] is, I believe, the best solution to
date. It's significantly more secure than comparable products on the
market: Mozilla (or whichever server you choose to hold your data) still
doesn't have your data in the clear. The encryption grade is not quite
as strong as current Sync: if an attacker breaches the server and throws
significant computing power at the problem, he could recover your data.
But the data is still encrypted, and it's still a significant
key-cracking effort + server breach to get at your data.
My sense is that this is the right tradeoff: less crypto strength in
exchange for some very important new features that users have come to
expect in most other aspects of their online lives.
Is this drastic? I'm not convinced. Crypto is almost never the weakest
link or point of attack in a real-world scenario. We can get to a good
bit weaker than 128-bits before crypto becomes the attacker's target.
I am in favor of having an advanced option where users could choose to
keep the full-entropy key and lose the new features. But I think it's
important to highlight that, in most cases, there's little real security
to be gained, because crypto is surely not the weakest link.
-Ben
[1] http://benlog.com/articles/2011/12/21/encryption-is-mostly-not-magic/
[2] https://wiki.mozilla.org/BrowserID_Key_Wrapping
Richard Newman
Apr 12, 2012, 8:49:46 PM4/12/12
to
On Thursday, April 12, 2012 5:05:14 PM UTC-7, Ben Adida wrote:
> I am in favor of having an advanced option where users could choose to
> keep the full-entropy key and lose the new features. But I think it's
> important to highlight that, in most cases, there's little real security
> to be gained, because crypto is surely not the weakest link.
Totally agreed.
> I am in favor of having an advanced option where users could choose to
> keep the full-entropy key and lose the new features. But I think it's
> important to highlight that, in most cases, there's little real security
> to be gained, because crypto is surely not the weakest link.
To briefly address some of the concerns in this thread:
* Supporting third-party-run Sync servers remains a requirement, regardless of authentication mechanism. No worry there.
* The crypto scheme in storage version 6 is strictly stronger than in v5, with one exception: using key wrapping with an uploaded key gives an attacker a theoretical ability to attack your wrapped key, and a practical ability to use stolen credentials to get access to data protected by that key.
For the vast majority of users those are not a real concern; attacking the wrapped key is not a practical attack, so the risk is reduced to phishing credentials. As Ben mentioned: crypto isn't the weakest link here.
The Persona team is already addressing concerns around phishing, because they're broader than Sync.
And for those users who are really paranoid, we do intend to provide some mechanism for key exchange that does not terminate the chain of credentials in a network-accessible password-wrapped key. Preserving user choice around their security and privacy is one of our principles.
There are also lots of fun future possibilities around 2FA etc., but I don't think they're immediately relevant.
David Illsley
Apr 13, 2012, 4:35:00 AM4/13/12
to Gregory Szorc, dev-pl...@lists.mozilla.org
On Wed, Apr 11, 2012, at 06:25 PM, Gregory Szorc wrote:
>
> In order to facilitate Sync "just working" after logging in to Persona,
> the UK will need to be stored centrally. If the UK is not stored
> centrally nor always available, you are back to Sync's usability issues
> around pairing: you'd need some way to transmit the UK between clients.
>
> So, how do we plan to store the UK centrally? The general plan is to
> encrypt the UK on the client before it is uploaded to the Persona server
> for storage. How, exactly, we're not sure yet.
>
> The minimum proposal is to use PBKDF2 of your Persona login credentials
> (i.e., your Persona password) to derive a a password key (PWK). Then,
> we'd use the PWK to encrypt and sign the UK before uploading it to the
> server. Any client with the Persona credentials could download the
> encrypted UK from the Persona server and decrypt it with the PWK. On top
>
> In order to facilitate Sync "just working" after logging in to Persona,
> the UK will need to be stored centrally. If the UK is not stored
> centrally nor always available, you are back to Sync's usability issues
> around pairing: you'd need some way to transmit the UK between clients.
>
> So, how do we plan to store the UK centrally? The general plan is to
> encrypt the UK on the client before it is uploaded to the Persona server
> for storage. How, exactly, we're not sure yet.
>
> The minimum proposal is to use PBKDF2 of your Persona login credentials
> (i.e., your Persona password) to derive a a password key (PWK). Then,
> we'd use the PWK to encrypt and sign the UK before uploading it to the
> server. Any client with the Persona credentials could download the
> of that, the current proposal is for Mozilla to be the only entity
> within the BrowserID ecosystem that stores encrypted UKs. Even IdP's
> (which you trust to issue credentials to you) wouldn't have this
> information.
Apologies if I've missed it, but I'm not clear how this will work with
> within the BrowserID ecosystem that stores encrypted UKs. Even IdP's
> (which you trust to issue credentials to you) wouldn't have this
> information.
non-browserid.org-hosted persona accounts (i.e. for domains with primary
support like eyedee.me)
In those cases, the browserid implementation doesn't know what the
password is, so I don't know how the above can be applied? Or is the
plan to only support browserid.org accounts with a password (maybe a
dummy @sync id with password for users with a main identity with primary
support?
Cheers,
David
David Illsley
Apr 13, 2012, 5:54:33 AM4/13/12
to dev-pl...@lists.mozilla.org
wrapping product/security questions" thread in services-dev:
On Wed, Apr 11, 2012 at 3:45 AM, Ben Adida <bena...@mozilla.com> wrote:
> On 4/10/12 7:42 PM, Mike Connor wrote:
>>
>>
>> So if I'm using a non-Persona IdP I'll have a second passphrase for
>> key wrapping? I won't just, say, sign into my google account and be
>> able to use the service?
>
>
> The way it will likely work (and I know Dan is working through these issues
> as we speak) is that you'll type your Persona password to sign into the
> browser, but you'll be prompted for your gmail password if/when you want to
> use that address to authenticate to an actual web site.
>
> There are some details to work out. I recommend we not rathole on them just
> yet. At the very least, the core idea is that, just because you've delegated
> auth to an IdP, doesn't mean you've delegated confidentiality, too.
Sam Tobin-Hochstadt
Apr 13, 2012, 8:33:23 AM4/13/12
to
On Thursday, April 12, 2012 8:05:14 PM UTC-4, Ben Adida wrote:
> Persona-based Signin-to-the-Browser using key-wrapping, described in the
> talk and a bit more on the wiki [2] is, I believe, the best solution to
> date. It's significantly more secure than comparable products on the
> market: Mozilla (or whichever server you choose to hold your data) still
> doesn't have your data in the clear. The encryption grade is not quite
> as strong as current Sync: if an attacker breaches the server and throws
> significant computing power at the problem, he could recover your data.
> But the data is still encrypted, and it's still a significant
> key-cracking effort + server breach to get at your data.
This is an effective level of defense against many attackers. However, it's a pretty ineffective level of defense, if I understand correctly, against a government subpoena for the hard drive and industrial levels of computer time for key-cracking. The current Sync architecture, as I understand it, would require either some technology breakthrough or some as-yet-undiscovered crypto advance to crack, especially with the upgrade to AES-256.
> Persona-based Signin-to-the-Browser using key-wrapping, described in the
> talk and a bit more on the wiki [2] is, I believe, the best solution to
> date. It's significantly more secure than comparable products on the
> market: Mozilla (or whichever server you choose to hold your data) still
> doesn't have your data in the clear. The encryption grade is not quite
> as strong as current Sync: if an attacker breaches the server and throws
> significant computing power at the problem, he could recover your data.
> But the data is still encrypted, and it's still a significant
> key-cracking effort + server breach to get at your data.
Maybe we shouldn't worry about this, because the crypto isn't the weakest link against the government, just as it isn't against more "conventional" attackers. But it's worth being clear about.
Sam
Henri Sivonen
Apr 13, 2012, 9:00:09 AM4/13/12
to dev-pl...@lists.mozilla.org
On Thu, Apr 12, 2012 at 4:25 AM, Gregory Szorc <g...@mozilla.com> wrote:
> First, we have the user experience of Sync. It's hard to use. User studies
> have shown that many people don't grok the Sync setup and pairing process
> (especially the latter).
What *I* don't grok about it is why Mozilla asks the user to supply an
> First, we have the user experience of Sync. It's hard to use. User studies
> have shown that many people don't grok the Sync setup and pairing process
> (especially the latter).
email address and a password instead of Firefox generating random HTTP
Basic Auth credentials when setting up Sync for the first time.
To me after the initial setup that requires username/password for no
obvious good reason, pairing is pretty easy for me to grok. Also, it's
much easier for me to actually use than Opera's
username/password-based Opera Link. With Firefox, I don't need to
remember anything or look up anything anywhere else. One instance of
Firefox tells me what I need to enter into the other instance. With
Opera Link, I need to enter a password. I don't actually remember my
Opera password, because I want my password to be long and per-service
unique. Thus, every time I set up Opera Link, I need to look up my
Opera password from the secure place where I store it. My current
phone has now gone for months without Opera Link setup, because I
haven't gotten around to looking up my password. I have set up
Firefox Sync multiple times on the same phone simply by letting the
phone tell me what to type into a desktop computer.
What don't people grok about pairing in user studies? You have two
devices with you. One of them gives you a code, you type it into the
other one. Super-simple as far as I can tell as long as you have both
devices with you!
Is the problem being solved enough people don't actually have the two
devices with them (i.e. they are pairing desktop to desktop at home
and an office or something without having an intermediate phone or
laptop)? Or is the problem being solved that people are just
unfamiliar with this kind of pairing and expect to see an inferior
password-based experience? It would be super-sad to solve the latter
problem by giving them the inferior experience they expect!
Or is a problem that people expect to be able to recover the sync key
to using a password? If that's the problem being sold, why is it
being solved? After all, you haven't lost your data unless you've
lost all the devices that your data has been synchronized to. So
instead of trying to recover the key, you could generate a new one and
reupload the data from one of your Firefox instances that you still
have.
> When a new Sync client needs to access your data, it would log in to
> Persona, fetch the wrapped Sync Key from the Sync server, then hand off the
> wrapped data to Persona and get back the original Sync Key.
> In order to facilitate Sync "just working" after logging in to Persona, the
> UK will need to be stored centrally.
As a user of Firefox Sync, I feel this is a pretty bad bait and
> UK will need to be stored centrally.
switch. Mozilla has got me hooked on the convenience of Sync so now I
don't want to stop using Sync. However, when I signed up, the deal was
that Mozilla doesn't receive all the data required for decryption.
Storing the Sync key on Mozilla's server in a form that can be
decrypted with a password that I also have to send to Mozilla's
servers is a fundamental change and the change I didn't sign up for
when I started using Sync. (When I say "I" that also applies to the
other users.) The proposed change basically weakens the security model
of Firefox Sync to that of Opera Link. (I currently sync my site login
passwords via Firefox Sync but I don't do the same with Opera Link.
I've kept my Opera Link usage only to bookmarks, which are relatively
low-sensitivity data compared to site passwords.)
Will the old key management and pairing model cease to be available as
an option? It would be a shame if the old model didn't stick around as
an option.
With the old model, in order for Mozilla to compromise the data of an
account, Mozilla would have had to supply a Trojaned Sync client to
the user. With the new model, Mozilla could compromise the data of an
account at its own end using data that the user supplies to Mozilla's
servers. Has this distinction been analyzed in the light of what e.g.
subpoenas can compel Mozilla to do? I wouldn't be at all surprised if
"send Trojaned software for someone else to execute" and "perform
certain computations at your end when someone else sends you all the
inputs of the computation" were treated as legally different cases
although one might argue that the technical level of trust that needs
to be placed in Mozilla is the same in both cases.
--
Henri Sivonen
hsiv...@iki.fi
http://hsivonen.iki.fi/
Ben Adida
Apr 13, 2012, 9:36:26 AM4/13/12
to
On 4/13/12 5:33 AM, Sam Tobin-Hochstadt wrote:
> This is an effective level of defense against many attackers.
> However, it's a pretty ineffective level of defense, if I understand
> correctly, against a government subpoena for the hard drive and
> industrial levels of computer time for key-cracking.
I agree with you, assuming the attacker is specifically targeting you.
> This is an effective level of defense against many attackers.
> However, it's a pretty ineffective level of defense, if I understand
> correctly, against a government subpoena for the hard drive and
> industrial levels of computer time for key-cracking.
In that case, as you also point out, the likelihood that crypto is the
weakest link is pretty low.
In the case that the attacker is on a fishing expedition and wants lots
of user data, not knowing ahead of time which is valuable, I remain
optimistic that we can make the work factor for password breaking
sufficiently high per user that this would be quite expensive, even for
a resourceful attacker.
And as you point out, we're now in the realm of an attacker who has
access to the server-side data.
> Maybe we shouldn't worry about this, because the crypto isn't the
> weakest link against the government, just as it isn't against more
> "conventional" attackers. But it's worth being clear about.
require careful documentation and continued community oversight!
-Ben
Ben Adida
Apr 13, 2012, 9:49:08 AM4/13/12
to
On 4/13/12 6:00 AM, Henri Sivonen wrote:
> As a user of Firefox Sync, I feel this is a pretty bad bait and
> switch. Mozilla has got me hooked on the convenience of Sync so now I
> don't want to stop using Sync. However, when I signed up, the deal was
> that Mozilla doesn't receive all the data required for decryption.
> Storing the Sync key on Mozilla's server in a form that can be
> decrypted with a password that I also have to send to Mozilla's
> servers is a fundamental change and the change I didn't sign up for
> when I started using Sync.
One important misunderstanding in the above: you will *not* be sending
> As a user of Firefox Sync, I feel this is a pretty bad bait and
> switch. Mozilla has got me hooked on the convenience of Sync so now I
> don't want to stop using Sync. However, when I signed up, the deal was
> that Mozilla doesn't receive all the data required for decryption.
> Storing the Sync key on Mozilla's server in a form that can be
> decrypted with a password that I also have to send to Mozilla's
> servers is a fundamental change and the change I didn't sign up for
> when I started using Sync.
your password to Mozilla. Before signin-to-the-browser is implemented,
Persona will switch to using SRP [1], a zero-knowledge proof of
knowledge of password. (In fact it will be SRP done on some
key-derivation of your password, so that the server never sees your
password in the clear.)
In other words, at no point, not even transiently, will Mozilla have all
the bits to simply decrypt your data. Like any attacker with access to
the server storage, Mozilla would still have to do some heavy-duty key
cracking.
There *is* a change: the key cracking difficulty is now dependent on the
entropy of your password. But there will be no way for Mozilla to bypass
the key cracking step.
One place where I'm optimistic, by the way, is in finding ways for users
to select, remember, and not misuse more secure passwords. I think there
is huge opportunity for improvement, based on combined security and UI
research. We'll probably start with the XKCD recommendations [2].
-Ben
[1] http://en.wikipedia.org/wiki/Secure_Remote_Password_protocol
[2] http://xkcd.com/936/
Zack Weinberg
Apr 13, 2012, 1:25:29 PM4/13/12
to
On 2012-04-13 6:49 AM, Ben Adida wrote:
> One place where I'm optimistic, by the way, is in finding ways for users
> to select, remember, and not misuse more secure passwords. I think there
> is huge opportunity for improvement, based on combined security and UI
> research. We'll probably start with the XKCD recommendations [2].
An acquaintance of mine has a sketch proposal (needs substantial work to
> One place where I'm optimistic, by the way, is in finding ways for users
> to select, remember, and not misuse more secure passwords. I think there
> is huge opportunity for improvement, based on combined security and UI
> research. We'll probably start with the XKCD recommendations [2].
be finished) for converting large random numbers into easily memorable
nonsense phrases. Written as a way to make Tor .onion URLs more
memorable, but might be reusable in this context as well.
https://gitweb.torproject.org/torspec.git/blob/HEAD:/proposals/194-mnemonic-urls.txt
Matt Brubeck
Apr 13, 2012, 5:58:23 PM4/13/12
to
On 04/13/2012 06:00 AM, Henri Sivonen wrote:
> Is the problem being solved enough people don't actually have the two
> devices with them (i.e. they are pairing desktop to desktop at home
> and an office or something without having an intermediate phone or
> laptop)?
Yes, this is a common problem on SUMO.
> Is the problem being solved enough people don't actually have the two
> devices with them (i.e. they are pairing desktop to desktop at home
> and an office or something without having an intermediate phone or
> laptop)?
> Or is a problem that people expect to be able to recover the sync key
> to using a password?
> If that's the problem being sold, why is it
> being solved? After all, you haven't lost your data unless you've
> lost all the devices that your data has been synchronized to. So
> instead of trying to recover the key, you could generate a new one and
> reupload the data from one of your Firefox instances that you still
> have.
their Firefox data. I think in most cases they had only one device to
begin with.
Why did these users set up sync at all? Because they thought it would
back up their data, and/or because they thought they might sync another
device in the future. We encourage users to create a sync account on
about:home and other places in the UI, without asking first whether they
have multiple devices.
Mike Hommey
Apr 14, 2012, 2:14:20 AM4/14/12
to Matt Brubeck, dev-pl...@lists.mozilla.org
encouragement messages on the desktop UI.
BTW, it almost feels like nagging, in the mobile UI, because it's big,
visually stands out, and appears until you do setup sync. (you can't
just make it go away *without* setting up sync)
OTOH, its message is pretty clear: "Set up Firefox Sync to access
bookmarks, history and tabs from your other devices."
Mike
Matt Brubeck
Apr 14, 2012, 11:17:52 AM4/14/12
to
On 04/13/2012 11:14 PM, Mike Hommey wrote:
> On Fri, Apr 13, 2012 at 02:58:23PM -0700, Matt Brubeck wrote:
>> Why did these users set up sync at all? Because they thought it
>> would back up their data, and/or because they thought they might
>> sync another device in the future. We encourage users to create a
>> sync account on about:home and other places in the UI, without
>> asking first whether they have multiple devices.
>
> I guess you're referring to mobile here, because I don't remember seeing
> encouragement messages on the desktop UI.
Desktop Firefox 10 through 13 have a link on about:home that says "set
> On Fri, Apr 13, 2012 at 02:58:23PM -0700, Matt Brubeck wrote:
>> Why did these users set up sync at all? Because they thought it
>> would back up their data, and/or because they thought they might
>> sync another device in the future. We encourage users to create a
>> sync account on about:home and other places in the UI, without
>> asking first whether they have multiple devices.
>
> I guess you're referring to mobile here, because I don't remember seeing
> encouragement messages on the desktop UI.
up sync" which launches straight into the registration workflow.
The new about:home design in Firefox 14 instead has a "Sync" button that
opens the sync preferences pane, which contains one sentence of
introductory text. This offers a bit more explanation, but I'm certain
many users will still think that their data is "backed up" on the server
because that's true of every other sync service they use (e.g. Dropbox,
Chrome sync, Amazon Whispernet, etc.).
One of the most terrible (but common) cases is when a user is replacing
or reformatting a computer, and sets up sync first so their data won't
be lost. Of course it is, because when they try to log in to sync on
the new computer they don't have the encryption key:
https://support.mozilla.org/en-US/questions/794681
Another common case is iOS users, since our iOS client does not let you
recover the encryption key. (This was also true of mobile Firefox until
version 10, and we could decide to fix in a future iOS client, but it
would arise again any time we create a client that does not offer the
full two-way pairing workflow.)
https://support.mozilla.org/en-US/questions/886580
Henri Sivonen
Apr 18, 2012, 5:39:54 AM4/18/12
to dev-pl...@lists.mozilla.org
On Fri, Apr 13, 2012 at 4:49 PM, Ben Adida <bena...@mozilla.com> wrote:
> On 4/13/12 6:00 AM, Henri Sivonen wrote:
>>
>> As a user of Firefox Sync, I feel this is a pretty bad bait and
>> switch. Mozilla has got me hooked on the convenience of Sync so now I
>> don't want to stop using Sync. However, when I signed up, the deal was
>> that Mozilla doesn't receive all the data required for decryption.
>> Storing the Sync key on Mozilla's server in a form that can be
>> decrypted with a password that I also have to send to Mozilla's
>> servers is a fundamental change and the change I didn't sign up for
>> when I started using Sync.
>
> One important misunderstanding in the above: you will *not* be sending your
> password to Mozilla. Before signin-to-the-browser is implemented, Persona
> will switch to using SRP [1], a zero-knowledge proof of knowledge of
> password. (In fact it will be SRP done on some key-derivation of your
> password, so that the server never sees your password in the clear.)
Can this, please, be publicized clearly whenever Sync 2.0 is presented
> On 4/13/12 6:00 AM, Henri Sivonen wrote:
>>
>> As a user of Firefox Sync, I feel this is a pretty bad bait and
>> switch. Mozilla has got me hooked on the convenience of Sync so now I
>> don't want to stop using Sync. However, when I signed up, the deal was
>> that Mozilla doesn't receive all the data required for decryption.
>> Storing the Sync key on Mozilla's server in a form that can be
>> decrypted with a password that I also have to send to Mozilla's
>> servers is a fundamental change and the change I didn't sign up for
>> when I started using Sync.
>
> One important misunderstanding in the above: you will *not* be sending your
> password to Mozilla. Before signin-to-the-browser is implemented, Persona
> will switch to using SRP [1], a zero-knowledge proof of knowledge of
> password. (In fact it will be SRP done on some key-derivation of your
> password, so that the server never sees your password in the clear.)
to the public so that we can avoid a user/media backlash from
seemingly weakened security and that we avoid losing our perceived
security advantage over competition?
> There *is* a change: the key cracking difficulty is now dependent on the
> entropy of your password. But there will be no way for Mozilla to bypass the
> key cracking step.
pass phrase from which the crypto key was derived.
Is there also another change: chaining your Sync key to the ability to
read your email? Presumably Persona will allow password recovery by
demonstrating the ability to read email sent to the address that's the
Persona user id. Will an attacker who gains access to the user's email
account and changes the Persona password be able to recover the
wrapped Sync key derived from the old password? (One might argue that
synced password are most likely already chained back to the ability to
read email plus the trouble to change each one. However, previously,
getting a dump of someone's browser history hasn't been chained back
to the ability to read that person's email.)
Ben Adida
Apr 18, 2012, 9:06:00 PM4/18/12
to
On 4/18/12 2:39 AM, Henri Sivonen wrote:
> Can this, please, be publicized clearly whenever Sync 2.0 is presented
> to the public so that we can avoid a user/media backlash from
> seemingly weakened security and that we avoid losing our perceived
> security advantage over competition?
Yes, preparing these materials as we speak, we didn't coordinate this
> Can this, please, be publicized clearly whenever Sync 2.0 is presented
> to the public so that we can avoid a user/media backlash from
> seemingly weakened security and that we avoid losing our perceived
> security advantage over competition?
thread very well, but that's my bad.
> OK, so we are back to the early days when the user had to supply a
> pass phrase from which the crypto key was derived.
> Is there also another change: chaining your Sync key to the ability to
> read your email?
passphrase. If you lose your password, you can regain the ability to
authenticate as yourself via resetting, but you will not be able to get
your Sync data back. Ideally the Firefox client will then reupload data
that it has cached.
There is *some* discussion of allowing partial recovery of certain
lower-security data in the future, but not without a longer discussion,
of course.
-Ben
0 new messages