Closed Bug 600644 Opened 9 years ago Closed 7 years ago

User entered secret phrases are not masked.

Categories

(Cloud Services Graveyard :: Firefox Home, defect)

x86
macOS
defect
Not set

Tracking

(Not tracked)

RESOLVED WONTFIX

People

(Reporter: rags, Unassigned)

References

Details

+++ This bug was initially created as a clone of Bug #598952 +++

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.
I'm not sure I agree with this, at least with the default. On a mobile device, shoulder surfing is much less likely. If I *am* in an environment where it's more likely, I could always turn the masking on, but I don't think it should be the default. Add on top of that that our 20 char Sync Keys are unwieldy enough to really pose a risk for shoulder surfing, but they can annoy you a lot if you have to enter them into a masked field.
(In reply to comment #1)
> I'm not sure I agree with this, at least with the default. On a mobile device,
> shoulder surfing is much less likely. If I *am* in an environment where it's
> more likely, I could always turn the masking on, but I don't think it should be
> the default. Add on top of that that our 20 char Sync Keys are unwieldy enough
> to really pose a risk for shoulder surfing, but they can annoy you a lot if you
> have to enter them into a masked field.

If there is some way to turn masking on by default for old school secret phrases, but off for auto-generated sync key (say by setting a pref?), would that work?

Unmasking the user set secret phrase feels weird for two reasons to me:
1. It is supposed to be even more secret than your password, but we now show it.
2. Users who were previously used to seeing it masked and are now going to be confused to see it unmasked.
(In reply to comment #2)
> (In reply to comment #1)
> > I'm not sure I agree with this, at least with the default. On a mobile device,
> > shoulder surfing is much less likely. If I *am* in an environment where it's
> > more likely, I could always turn the masking on, but I don't think it should be
> > the default. Add on top of that that our 20 char Sync Keys are unwieldy enough
> > to really pose a risk for shoulder surfing, but they can annoy you a lot if you
> > have to enter them into a masked field.
> 
> If there is some way to turn masking on by default for old school secret
> phrases, but off for auto-generated sync key (say by setting a pref?), would
> that work?

We can apply some heuristics when we show an already entered secret phrase (e.g. in the My Sync Key dialog in Fx Sync or the options in Fx Home and Fx Sync for Fennec). A secret phrase that's 20 characters long and only contains a-z is very likely to be a Sync Key, so show it.

This guesswork obviously doesn't work when the user is entering their secret phrase because at the first character we don't know how what the other characters are going to be and how many of them there are ;).

That said, consistency > guess work and DWIM interfaces.

> Unmasking the user set secret phrase feels weird for two reasons to me:
> 1. It is supposed to be even more secret than your password, but we now show
> it.
> 2. Users who were previously used to seeing it masked and are now going to be
> confused to see it unmasked.

So this is really about the existing users than about future users? Because if our use case is to just to not freak out old users, then let's do that and only that. New users or existing users going through the new wizard will obviously not be *as* surprised. We just need to take care of the users who go to the settings/login/My Sync Key dialog and freak out because their passphrase is shown in clear text, right?

If that's the case, let's try to detect whether somebody has upgraded from a previous version (vs having set up the device with the new wizard). If that's the case we continue to mask *until* the user goes through the setup/login screen again or changes their passphrase. I think that would be the least surprising behaviour for both user groups: no masking anywhere for all new users and old users who set up new devices using the new wizard, masking for old users that upgraded to the new version.
Depends on: 601644
No longer depends on: 598952
The Firefox Home project has been retired, and Mozilla will no longer invest in future work on this project [1]. All bugs related to Firefox Home are being mass resolved.

For those interested in continuing work on this app, the source code for Firefox Home is available on Github [2].

[1] http://blog.mozilla.org/services/2012/08/31/retiring-firefox-home/
[2] https://github.com/mozilla-services/ios-sync-client
Status: NEW → RESOLVED
Closed: 7 years ago
Resolution: --- → WONTFIX
Product: Cloud Services → Cloud Services Graveyard
You need to log in before you can comment on or make changes to this bug.