540975 - Warn when syncing passwords to a profile with no master password if master password is set elsewhere

Status: RESOLVED INACTIVE

(Firefox :: Sync, enhancement)

Description

[Ron Baldwin]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2) Gecko/20100115 Firefox/3.6
Build Identifier: 

Weave should warn during the setup wizard if you are about to sync your passwords and there is no master password.  Ideally, it should also warn if you turn on password syncing anytime after setup.

It would be nice if the warning gave you a check box to turn off password sync and/or a button to set a master password; see bug 540728 comment 7.  However, this would be secondary to warning the user in the first place.


Reproducible: Always

Comment 1

[Mike Connor [:mconnor]]

This should be done only if the user already has a master password set.

Comment 2

[Daniel Holbert [:dholbert]]

To clarify: this should be done only if the user already has a master password set *on his other machines*, and *not* on the computer that's currently being set up with Weave.

The current "failure" case is:
 (a) User has a profile with banking passwords saved in his profile.  This profile uses a strong master password to protect these, and it syncs with Weave.
 (b) User adds a new computer, with no master password, to his Weave cloud. (perhaps in order to sync down his bookmarks)  He doesn't realize that now his passwords are all available ***in the clear*** on that computer.
 (c) Someone borrows / steals / images his computer, and has all of his banking passwords. Game over.

As I understand it, this bug is about warning the user during step (b) above, to let him know his saved passwords, which until now haven't been stored in the clear anywhere, will now be stored in the clear on the computer that he's just added to his Weave cloud.

Comment 3

[junk]

Absolutely agree with this bug. When you connect from a new device that does not have a master password set, and pull across passwords from one/more devices where the master password is set you should be warned, and prompted to set a master password. 

I'd naively assumed that my master password would be pulled across. I can understand (From bug 540728) why this can't be enforced on all sync clients, but you should be told if the client you are syncing to does not support master passwords, or has the functionality not set.

Comment 4

[Mike Connor [:mconnor]]

The main problem with warning before sync is that Sync doesn't necessarily know, at the time you're syncing to the cloud, what other clients will be in the mix.  If you install Sync on Firefox, and Home on an iPhone after that... your passwords are already uploaded by that point, and you have the classic barn door/horse scenario.

Comment 5

[junk]

I don't think the fact that they've gone to the cloud is an issue. This is about pulling the data down to a client which supports a master password, but doesn't currently have one set where one or more of the other clients in the cloud *do* have one set. This bug is predominantly saying:

If the client supports a master password, then either:
a. Master passwords should be synced across to that client [Probably a no-go since people might want different passwords for different devices]
or
b. The client should warn that other clients in the cloud have a master password set, but this client does not - *before* any data is pulled down

Comment 6

[Mike Connor [:mconnor]]

(In reply to comment #5)
> If the client supports a master password, then either:
> a. Master passwords should be synced across to that client [Probably a no-go
> since people might want different passwords for different devices]

Master passwords aren't saved in Firefox directly.  It's actually a passphrase to an encryption key.  We could sync the key, and the encrypted versions of the passwords, in addition, but that's not necessarily what you want.

> b. The client should warn that other clients in the cloud have a master
> password set, but this client does not - *before* any data is pulled down

Just to be clear, we can't enforce this on all clients.  We can detect/warn in Firefox, but not all clients will be produced by Mozilla or somehow controlled by us.

Comment 7

[junk]

Indeed, hence "If the client supports a master password".

I guess for clarity this is a bug in the Firefox client rather than Sync in general.

Comment 9

[Dave Miller [:justdave]]

My suggestion from bug 580799 is to sync the passwords by default still encrypted with whatever method was in use on the originating machine.  If the client that's pulling it can support that encryption method, then you can start using it and you're good to go.  If it doesn't, then that client has no access to the data.

If this isn't what the user wants, then there would be an option to revert back to the behavior that it's using now, but the user would be warned before the data ever gets sent into the cloud that this would potentially make it available in the clear on clients that don't support the security device functionality.

Of course, syncing the data with it already encrypted is probably a logistics nightmare if you intend to deal with incremental changes made by multiple clients...

Comment 10

[Dave Miller [:justdave]]

And the reason you warn before it gets sent into the cloud is precisely *because* we have no control over who's writing the clients on the other devices, so we don't know whether those clients will warn the user before pulling it down in the clear or not.

Comment 12

[Gregory Szorc [:gps]]

We plan on recording whether a master password is set in the client record starting with the next version of the clients engine. Once that is in place, we can hook this feature up.

Comment 13

[Dave Miller [:justdave]]

(In reply to Dave Miller [:justdave] from comment #9)
> Of course, syncing the data with it already encrypted is probably a
> logistics nightmare if you intend to deal with incremental changes made by
> multiple clients...

I'm not sure this is still the case...  it appears that the current implementation of the password storage has the username and password fields individually encrypted within the table which is otherwise cleartext, rather than having the whole file encrypted.  This means syncing passwords that are already encrypted should be just as easy as syncing ones that aren't.

Comment 14

[Dave Miller [:justdave]]

(In reply to Gregory Szorc [:gps] from comment #12)
> We plan on recording whether a master password is set in the client record
> starting with the next version of the clients engine. Once that is in place,
> we can hook this feature up.

How does that fit in with comment 10?  Is the server going to enforce this where if any client has a master password set it won't let another client download them unless it also claims to have that set?  (i.e. you're not leaving the choice up to the client, right?)

Comment 15

[Richard Newman [:rnewman]]

(In reply to Dave Miller [:justdave] from comment #14)

> How does that fit in with comment 10?  Is the server going to enforce this
> where if any client has a master password set it won't let another client
> download them unless it also claims to have that set? 

I doubt it. The Sync server is pretty much a dumb store.

> (i.e. you're not
> leaving the choice up to the client, right?)

Firstly, the records are encrypted, so the server doesn't get a say.

Secondly, either you can trust the client, or you can't. If you can't, you also can't trust that the client isn't going to lie about having MP enabled...

Comment 16

[Richard Newman [:rnewman]]

(In reply to Dave Miller [:justdave] from comment #13)

> I'm not sure this is still the case...  it appears that the current
> implementation of the password storage has the username and password fields
> individually encrypted within the table which is otherwise cleartext, rather
> than having the whole file encrypted.  This means syncing passwords that are
> already encrypted should be just as easy as syncing ones that aren't.

The problem comes in unifying data between multiple sources. Sync doesn't have any control over the security device in use by pwmgr; to handle records from multiple sources with different MPs or encryption methods would be next to impossible.

Comment 17

[Dave Miller [:justdave]]

(In reply to Richard Newman [:rnewman] from comment #16)
> The problem comes in unifying data between multiple sources. Sync doesn't
> have any control over the security device in use by pwmgr; to handle records
> from multiple sources with different MPs or encryption methods would be next
> to impossible.

Sure, but is it ethical to just blindly do it without warning the user they might be exposing their passwords if a client doesn't encrypt them for storage?  I really don't think it should matter whether the client claims to support encrypted password storage or not, because anyone can write a client, and we can't control what the clients do. The user should get a warning when they enable password sync from any client that although Sync will encrypt them in transit, it is up to each client to encrypt them for local storage, and to be aware of that before syncing passwords to a new device. (Not that it helps much since the Android client can't handle it currently)

Comment 18

[Dave Miller [:justdave]]

(In reply to Dave Miller [:justdave] from comment #17)
> Sure, but is it ethical to just blindly do it without warning the user they
> might be exposing their passwords if a client doesn't encrypt them for
> storage?

Just for context here, I'm a decently tech-savvy person, and I had no clue the Android version of Firefox wasn't encrypting my passwords when I enabled password sync.  I just happened to realize AFTER THE FACT that it was autofilling my passwords before prompting me for a Master Password on my Android device.  You can't expect your average user to notice things like that, not to mention even the people who do realize it (like me) often won't until it's too late because it's already been done by the time you see the symptoms.

Comment 19

[Richard Newman [:rnewman]]

(In reply to Dave Miller [:justdave] from comment #18)
> You can't expect your average user to notice things like that, 

Are you aware of any user research that suggests what kinds of users (and how many) use MP?

> not to mention even the people who do realize it (like me) often won't
> until it's too late because it's already been done by the time you see the
> symptoms.

On the plus side, you can enable MP after you've stored passwords.


> Sure, but is it ethical to just blindly do it without warning the user they
> might be exposing their passwords if a client doesn't encrypt them for
> storage?

I can see both sides of this.

If you think of MP as some kind of preference attached to your password store itself, then I can see why you might want this preference propagated throughout your Sync constellation. But practicality intervenes.

Your email client doesn't warn you that other clients using IMAP can expose your messages to prying eyes, even though your email is probably the single most viable attack source for most people. And your open tabs and browser history might be bigger information leaks than your passwords, but we don't offer any kind of local encryption for those.

From a perspective of "MP is there if you're the kind of user who wants per-device extra local security", a mild notice here — "some of your devices have master password enabled; do you want to turn it on for this device?" — is more than enough.


> I really don't think it should matter whether the client claims to
> support encrypted password storage or not, because anyone can write a
> client, and we can't control what the clients do. The user should get a
> warning when they enable password sync from any client that although Sync
> will encrypt them in transit, it is up to each client to encrypt them for
> local storage, and to be aware of that before syncing passwords to a new
> device.

I'd be inclined to defer to UX here.

It's important for a warning to be actionable, relevant, and consistent across devices, and experience with the Sync setup UI indicates that crypto-related warnings and notices (e.g., "save your Sync recovery key somewhere") simply cause user confusion rather than enabling user action.

What you'd get by doing this is just users getting scared and canceling out of the setup process. What is my mother supposed to do when she sees a message saying "be careful! third-party clients or Firefox profiles without MP enabled don't protect your passwords on disk!"?

She doesn't know what a third-party client is, what Master Password is, or what she should do when that pops up on her screen.

In the worst case, she'll switch to a browser which takes even less care of your data, but scares her less.

I'd also encourage us to look at this whole problem in the context of Firefox as a whole, including future directions like sign-in-to-browser. Master password is quite user-hostile as it's currently implemented, and if our goal is to encourage people to use it on all of their devices if they use it on one (rather than accepting better/different solutions like whole-disk encryption), then we'd need to address that.

I would hate to see us scare the hell out of a FileVault or BitLocker user by telling them that their passwords are insecure, when those systems probably meet their security needs better than MP.

> (Not that it helps much since the Android client can't handle it
> currently)

Aye. Bug 711636 covers syncing with MP enabled.

Comment 20

[drummmer]

Wouldn't it be logical to warn the User and ask him to set a Master Password at the point he is saving Passwords to his Firefox Password storage? 

I wonder why this is handled that naive in Firefox today. I think this change would generally enhance the security for Users using Firefox. It would have nothing to do with sync but it would obsolete this discussion.

Comment 21

[Richard Newman [:rnewman]]

(In reply to drummmer from comment #20)
> Wouldn't it be logical to warn the User and ask him to set a Master Password
> at the point he is saving Passwords to his Firefox Password storage? 
> 
> I wonder why this is handled that naive in Firefox today. I think this
> change would generally enhance the security for Users using Firefox. It
> would have nothing to do with sync but it would obsolete this discussion.

Master Password is not as useful as you might think. Solutions like FileVault, Android's disk encryption, BitLocker, and PGP/TrueCrypt/etc. are much better at protecting your data "at rest".

About all MP is good for is preventing someone who already has access to your browser from using your stored passwords. That basically means your kids or your friends. Multiple profiles, browsers, or guest logins are better for that.

Comment 22

[drummmer]

(In reply to Richard Newman [:rnewman] from comment #21)
> (In reply to drummmer from comment #20)
> Master Password is not as useful as you might think. Solutions like
> FileVault, Android's disk encryption, BitLocker, and PGP/TrueCrypt/etc. are
> much better at protecting your data "at rest".
> 
> About all MP is good for is preventing someone who already has access to
> your browser from using your stored passwords. That basically means your
> kids or your friends. Multiple profiles, browsers, or guest logins are
> better for that.

I think the average Firefox user will not take advantage of the encryption tools you mentioned. So the most users will be unprotected. An advanced user who has already encrypted his hard drive knows what to do when a warning appears to use a MP (that he doesn't need to enable MP).

You're right. And the default behaviour (currently suggested by the Firefox browser) would be like you post the pin code of your credit card on your fridge and invite for a birthday party...

Comment 24

[Patrick Seiter]

Forget warnings. A master password should be part of your synced data if it is set on any device, no exceptions. As such, I filed bug 927963.

Comment 25

[Hamish Blair]

As far as I can see this is still a bug. I sync'd my passwords across to a new computer a few weeks ago and only just realised there's no master password on my new machine (well, there is now I've set it!)

Comment 26

[Ryan Kelly [:rfkelly]]

+:lina, maybe something we can take into consideration when looking at integration for the new logins component?

Comment 27

[janet [:janet]]

We are going to revisit master password handling as part of the logins component work for desktop.

Comment 29

[Dinar]

you could add just a warning in the dialogs like "be aware, if you sync before setting master password, your passwords may be exposed to malware", while bug is not fixed other way.