Closed Bug 1000164 Opened 8 years ago Closed 4 years ago
Request a lock code when one is not set when enableing Where's My Fox / Find My Device
When a user enables this feature we may want to request they set a lock code if one is not set to help increase the security and reduce the mis-use case where theft or lost devices could have the feature easily disabled when no lock code is set
JR, please correct me if I'm wrong, but I think we already have plans for asking for a passcode in the web interface before locking, if there is none on the device, right? Note that disabling FMD will require re-entering the password for FxA (as soon as bug 1000323 lands), which is presumably our last and strongest line of defense, so not having a lock code when the device is stolen should be irrelevant to that disabling.
There's the ability for the website to set a lock code for any device without one. The only way to lock a given device is for a lock code to either be already present on the device, or passed from the website. I don't know if this is different than what is being asked, that during FMD initialization, an initial lock code is requested from the user. (This does mean that the website would probably lose the ability to set lock codes, since one would always be set on the device. This is a good thing.)
(In reply to JR Conlin [:jrconlin,:jconlin] from comment #2) > (This does mean that the website would probably lose the ability to set lock > codes, since one would always be set on the device. This is a good thing.) In my opinion, it should be possible to set a pass code from the website if there is none on the device. I have two reasons for that. First, not doing so and only requiring a passcode at the moment FMD is enabled doesn't guarantee that there will still be a pass code later, when the device is lost/stolen. That is, it's quite possible for someone to enable FMD while not having a pass code, then be prompted to set a pass code as part of the enabling process, then weeks later remove that pass code, and be left in a state where FMD is enabled with no lock code. That sounds like a tricky UX problem, as opposed to just asking for a pass code on the website when/if we need it. The second is admittedly a pet peeve of mine: having the website ask for a pass code could be part of the plan to always lock the screen before any other commands. If the user logs in to the website and asks to track the device (or whatever other action), we could first of all lock the screen, and if no pass code is set on the device the website just needs to ask for one then and there. So to me this bug is about deciding whether we want to ask for a pass code when FMD is enabled _in addition to_ having the possibility to set one from the website later if necessary, but not as a replacement to that.
Ah! sorry if there was any confusion about this. I meant that since there would probably be a lock code on the phone at all times, the website probably would display a disabled lock code setter most of the time. I didn't think that the lock code could be removed once set, so yes, when that happens the website would again be able to set the code. tldr: +1
Nick: this is inherently provided by the user entering "Lost Mode", correct?
I think this line from ggp sums up the issue best: "So to me this bug is about deciding whether we want to ask for a pass code when FMD is enabled _in addition to_ having the possibility to set one from the website later if necessary, but not as a replacement to that." We still need to make that call. The website will let the user set a passcode if none is set when they initiate "Lost Mode", but that doesn't address the initial question about whether or not we should prompt the user to enter a passcode on device when they enable FMD. I don't have a strong opinion about what we should do in that case. If we fundamentally believe that having a passcode is a good idea in the most general sense, then I think it's a good idea to to go ahead and prompt users to do it as part of enabling FMD. If we don't care, then there's no technical reason we have to force them to create a passcode.
I feel that it is too prescriptive to predicate enabling FMD on having a lock code as to disable FMD the user (or thief) will have to enter the FxA password which should be a good deterrent.
Sorry if this sounds like me being a jerk, but let me approach this as someone intent on stealing your phone: I don't care if i need a passcode to disable FMD. I'm not going to do that. Instead, I'm going to do whatever gives me the highest profit for the short term. In that case, I'm going to shut the device down however I can, bring it somewhere it can't connect to the outside world (e.g. wrap it with foil), and either reflash it or wipe it clean so I can sell it on a black market table. If I'm a party interested in the data on the device, and steal it, inhibit it the same sort of way, and then either force break the passcode (if it takes 1s to enter a code, it takes a max of 2hours, 46minutes and 38 seconds to solve it), or use a USB/bootloader exploit to bypass internal security and pull data off the phone. If I'm a government, it's even easier since they have sophisticated tools that can do this pretty automatically, unless they decide to go the rubber hose and hostage route, in which case, you'll do it for them. So, there's that. Now, all that aside, what are we trying to do here? The vast majority of cases will be either incompetent thieves (aka children or jealous associates) or forgetful owners. Really, the lock code prevents casual misuse of the device. Most folks will probably use WMD to figure out their phone is at the cafe and want it to ring loudly enough (and post a message to the shopkeep) that they will be back down there to pick it up. I would greatly prefer that these devices strongly urge users to set a passcode, right from the start. I would greatly prefer that FxA devices had a lockout period after multiple wrong password attempts. Passcodes should be set to access the phone and make purchases. I'd prefer if the passcode was required to launch the settings app, but that's fairly debatable. I think having a passcode to log off is probably overkill considering the number of ways that the phone can be compromised. </jerk>
Correction: pdehaan points out bug 888911, which introduces a growing delay to slow brute force attacks. This increases the attack time, making brute force significantly harder. So, the sophisticated data thief would be better off looking for other exploits.
JR, point well taken on the need to educate the user to set the lock code. But I think it is better done at the First run experience (FTE) rather than at a feature level.
Consensus is: We should ask ask for a passcode from the user if there isn't one set already (this is current behavior). +1 to what Vishy said.
Should we expect this to land in 2.0?
Whiteboard: backlog-2.1 → backlog-2.1; server 2.1
Firefox OS is not being worked on
Status: NEW → RESOLVED
Closed: 4 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.