Bugzilla

Daniel Holbert [:dholbert]

Comment 1

•

15 years ago

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

Severity: critical → enhancement

Status: UNCONFIRMED → NEW

Ever confirmed: true

Summary: Warn when syncing passwords to a profile with no master password → Warn when syncing passwords to a profile with no master password if master password is set elsewhere

Target Milestone: --- → Future

Comment 2

•

15 years ago

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.

Updated

•

14 years ago

Component: General → Sync

QA Contact: general → sync

junk

Comment 3

•

14 years ago

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

•

14 years ago

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.

junk

Comment 5

•

14 years ago

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

•

14 years ago

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

junk

Comment 7

•

14 years ago

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

•

14 years ago

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

Curtis Koenig [:curtisk-use curtis.koenig+bzATgmail.com]]

Comment 10

•

14 years ago

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.

Daniel Veditz [:dveditz]

Updated

•

14 years ago

Whiteboard: [sg:want]

Gregory Szorc [:gps]

Comment 12

•

12 years ago

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.

Depends on: 745412

Updated

•

12 years ago

Keywords: sec-want

Comment 13

•

12 years ago

(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

•

12 years ago

(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

•

12 years ago

(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

•

12 years ago

(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

•

12 years ago

(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

•

12 years ago

(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

•

12 years ago

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

drummmer

Comment 20

•

12 years ago

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.