Closed Bug 598952 Opened 14 years ago Closed 8 years ago

User entered secret phrases are not masked.

Categories

(Firefox :: Sync, defect)

x86
macOS
defect
Not set
normal

Tracking

()

RESOLVED WONTFIX

People

(Reporter: zandr, Unassigned)

References

Details

There have been hallway discussions about this, and all options have issues, but I think we should take another look at this.

I find it very jarring that the most powerful secret in the system can be trivially shoulder-surfed. We have a ton of messaging around "keep this secret", but we'll mask the far less powerful password and not the very powerful sync key?

I'm very well aware that entering an autogenerated sync key into a masked box will be a pain. Those are hard to read and hard to remember, so I see the value in having those unmasked.

Apple took a middle road with the "Show Password" button in many auth dialogs, and that might be a way to go. It will require strings, but the same strings as one path for bug 598948.

I think this is going to look really bad when it goes mainstream. This looks like an obvious mistake for a product where key brand promises are privacy and security.
Blocks: 600644
(In reply to comment #0)
> I find it very jarring that the most powerful secret in the system can be
> trivially shoulder-surfed. We have a ton of messaging around "keep this
> secret", but we'll mask the far less powerful password and not the very
> powerful sync key?

I find shoulder surfing a 20 char Sync Key pretty hard. Or are we worried about the users we've already got and their custom passphrases? Let's try to be clear about the use case here.

> I'm very well aware that entering an autogenerated sync key into a masked box
> will be a pain. Those are hard to read and hard to remember, so I see the value
> in having those unmasked.
> 
> Apple took a middle road with the "Show Password" button in many auth dialogs,
> and that might be a way to go. It will require strings, but the same strings as
> one path for bug 598948.

I agree that the "My Sync Key" dialog should be MP protected (bug 598948) and perhaps in that dialog we should mask at first. In general, though, I think Apple got that default the wrong way around.

In the setup wizard for setting up another computer, for instance, I don't think we should mask by default. Most of our users will eventually have the 20 char Sync Key which I find pretty hard to shoulder surf. Not only that, they will most likely copy'n'paste it from their Sync Key Artifact or read it off their printed version of that anyway. Both methods mean the Sync Key is already available somewhere else in plain text; I fail to see why we should mask then.

In the off chance that the user does have a custom key, we can always provide an option to mask before they enter it. But I don't think this has to be the default. *Especially* on a mobile device.

> I think this is going to look really bad when it goes mainstream. This looks
> like an obvious mistake for a product where key brand promises are privacy and
> security.

Perhaps. It might also look really kludgy when users mistype their 20 char Sync Keys all the time on their Android phone...


To summarize, I think we should...

* not mask when the user is setting up a new account. Doesn't make sense for the generated Sync Key because we actually want the user to see it. For custom ones we might present the option to mask it, but it's not the default.

* not mask when the user is setting up another computer, but give the option to mask it (includes Fennec)

* ask for MP (if present) before the Sync Key dialog. I still don't think the Sync Key should be masked at this point either because it'll most likely be a generated one and the dialog serves to review it, not just to change it. When changing it to a custom one we might once again present the option to mask it, but not the default.
>Apple took a middle road with the "Show Password" button in many auth dialogs,
>and that might be a way to go.

I'm ok with displaying this in the event that the sync key is user generated (not the correct length with hyphens at certain points).  For automatically generated sync keys shoulder surfing isn't much of a concern, unless the person behind you is rapidly writing things down in a notebook for 10 seconds.
>* ask for MP (if present) before the Sync Key dialog. 

This makes sense, we also ask before the user can access the password manager.
I should note that I mean I'm ok with masking in the "my sync key" dialog box, only if the key is user generated.  During account creation and setting up a second computer the user correctly entering the information should take precedence over the chance of prolonged shoulder surfing.
No longer blocks: 600644
This bug only affects Sync 1.1, and it was shut down in the fall of 2015 (https://blog.mozilla.org/services/2015/07/31/shutting-down-the-legacy-sync-service/).
Status: NEW → RESOLVED
Closed: 8 years ago
Resolution: --- → WONTFIX
Component: Firefox Sync: UI → Sync
Product: Cloud Services → Firefox
You need to log in before you can comment on or make changes to this bug.