bugzilla.mozilla.org has resumed normal operation. Attachments prior to 2014 will be unavailable for a few days. This is tracked in Bug 1475801.
Please report any other irregularities here.

Support stronger password in lockscreen

RESOLVED WONTFIX

Status

Firefox OS
Gaia::System::Lockscreen
RESOLVED WONTFIX
5 years ago
a year ago

People

(Reporter: pauljt, Unassigned)

Tracking

({sec-want})

unspecified
x86
Mac OS X
sec-want
Dependency tree / graph

Firefox Tracking Flags

(tracking-b2g:backlog)

Details

Attachments

(1 attachment, 3 obsolete attachments)

We should support more than just a 4-digit password for security minded users. Changes are needed to the lockscreen UI and settings apps (amongst others?) in order to provide support for complex passwords
Component: Gaia::System → Gaia::System::Lockscreen
This is an important feature because without it we are limiting the security choices of our users. Nominating for koi.
blocking-b2g: --- → koi?

Comment 2

5 years ago
Created attachment 776624 [details] [diff] [review]
Backend Patch WIP

This is just a WIP patch that handles the actual SHA256 hashing of a string passed via MozContentEvent to the shell. There is a question here, what kind of passphrase requirements / restrictions we might have. I imagine the front end code could pretty easily consume this code, but will require full keyboard lock/unlock ability. I think the existing code has a dedicated 4-digit unlock screen.
Attachment #776624 - Flags: feedback?(ptheriault)

Comment 3

5 years ago
Dietrich, Paul:
Do you know who might own the unlock front-end code? I am happy to work on the front end as well. I just want to coordinate with whoever might review it and find out what specs they might have in mind here.

Updated

5 years ago
Assignee: nobody → ddahl

Comment 4

5 years ago
Created attachment 776782 [details] [diff] [review]
Backend WIP patch

Fixed a minor mistake
Attachment #776624 - Attachment is obsolete: true
Attachment #776624 - Flags: feedback?(ptheriault)
Attachment #776782 - Flags: feedback?(ptheriault)
I'm sure exactly who owns the lockscreen frontend - maybe Tim? Or Tim I assume might know who does if it isn't you?
Flags: needinfo?(timdream)
Blocks: 876345
$ git blame --line-porcelain -- apps/system/js/lockscreen.js | grep "author " | sort | uniq -c | sort -nr
 497 author Timothy Guan-tin Chien
 180 author Vivien Nicolas
  88 author Yuren Ju
  44 author Andreas Gal
  42 author Alive Kuo
  32 author Kevin Grandon
  25 author Julien Wajsberg
  20 author Fabien Cazenave
  17 author Gabriele Svelto
  17 author Fabrice Desré
  17 author Eitan Isaacson
  15 author Mihai Cirlanaru
  14 author James Lal
  12 author Etienne Segonzac
  11 author Rex Lee
  11 author David Flanagan

$ git count -- apps/system/js/lockscreen.js
    95  Timothy Guan-tin Chien
    22  Vivien Nicolas
    13  Fabien Cazenave
     8  David Flanagan
     8  Yuren Ju
     7  vingtetun
     7  Etienne Segonzac
     5  Anthony Ricaud
     5  Alive Kuo
     4  Andreas Gal

It's Andreas!

... anyway, I would like to know why do we need a "backend" on this. The passcode is currently stored in mozSettings database and protected by it's permission control.

If we really need that, please patch shell.js in another bug under Boot2Gecko::General.

With that I am happy to patch the Gaia front-end if I am told what exactly the "back-end" do, or find someone in my team to do so.
Flags: needinfo?(timdream)

Comment 7

5 years ago
(In reply to Tim Guan-tin Chien [:timdream] (MoCo-TPE) from comment #6)
> $ git blame --line-porcelain -- apps/system/js/lockscreen.js | grep "author

Thanks. The question was not "who wrote this", it was "who owns it and is planning or cares about enhancements"?

> ... anyway, I would like to know why do we need a "backend" on this. The
> passcode is currently stored in mozSettings database and protected by it's
> permission control.

It is a laughably bad practice to store any kind of passphrase or pin in clear text. The backend is needed because the fast crypto needed for sha256 is not going to happen in JS, and we already have interfaces in Gecko.

Comment 8

5 years ago
I chatted with timdream last night at length. It turns out the settings app does not have access to mozChromeEvent. 

timdream said that mozChromeEvent would be deprecated in the future as well, and I imagine the fact that the settings app has no access to it might be for security? I am not sure.

The 2 options we have here are:

1. Use an existing SHA256 implementation in JS. This seems like a bad idea to me as it will be slow and getting review on this might take some time.

2. create a web API: navigator.mozCrypto or navigator.mozHash, with  a simple "hash" function (like the patch that is attached here) that just hashes a single string - with the option of SHA256, 384 and 512.

Gregor: What do you think about these options?
Flags: needinfo?(anygregor)

Comment 9

5 years ago
After talking to Gregor on irc and looking at the SettingsManager code in dom/settings, it seems like we can add the hashing function to SettingsManager. When the passcode is saved to the database, it can be hashed. 

When a passcode confirm step is initiated, we can enqueue a request to hash the typed in passcode. Then we compare the hashes before unlocking the screen.

The UI bits are allowing the usage of the full keyboard to create a passcode of any length up to ?? (whatever is decided: 16, 32 char?). This will also require changing the hardcoded length limits in gaia/apps/settings/js/phone_lock.js
This would solve the lockscreen passcode problem. The question is if we want a general solution that would work for other passwords as well where we have to get the original value out of the DB.
Flags: needinfo?(anygregor)

Comment 11

5 years ago
(In reply to Gregor Wagner [:gwagner] from comment #10)
> This would solve the lockscreen passcode problem. The question is if we want
> a general solution that would work for other passwords as well where we have
> to get the original value out of the DB.

I think we should create a hashing JSM we can import and use in any WebAPI's workflow. Would that be general enough as each API might want to create different hashes, etc?
Keywords: sec-want

Comment 12

5 years ago
Created attachment 779447 [details] [diff] [review]
fix-homescreen-pin

I changed the patch I imagine this living with SettingsManager. So far a JSM  called SettingsHash we can use inside of settings code to hash any setting that needs it.

I imagine the JSM can also be used by whatever code saves the WIFI passcode as well.
Attachment #776782 - Attachment is obsolete: true
Attachment #776782 - Flags: feedback?(ptheriault)
Attachment #779447 - Flags: feedback?(anygregor)

Comment 13

5 years ago
Created attachment 779450 [details] [diff] [review]
Patch 1: SettingsHash.jsm

forgot hg add
Attachment #779447 - Attachment is obsolete: true
Attachment #779447 - Flags: feedback?(anygregor)
Attachment #779450 - Flags: feedback?(anygregor)

Comment 14

5 years ago
After meeting about this issue and larger issues, sounds like this is on hold until Paul comes up with a more comprehensive plan for lock screen security.

Updated

5 years ago
Attachment #779450 - Flags: feedback?(anygregor)

Updated

5 years ago
Assignee: ddahl → nobody
Push this to v1.3 since v1.2 has been feature frozen.
blocking-b2g: koi? → 1.3?
Moving to backlog for now.
ni to Paul if there are more updates as per Comment 14.
Blocks: 908549
Flags: needinfo?(ptheriault)
This bug doesn't really need more information I think. The point of the bug was that currently we only support 4 digit pin codes. We should more secure passwords (ie passwords of arbitrary length). The patch supports this in that if we are going to support longer passwords, we shouldn't just be storing the password in a setting, and instead storing a hash, and comparing the hash. But this probably isnt the big change here - we need UX, lockscreen and settings app changes to support a password of arbitrary length.
Flags: needinfo?(ptheriault)
Moving out of 1.3 as it looks to be a fairly large amount of work.
blocking-b2g: 1.3? → 1.4?

Comment 19

5 years ago
Flagging Rob as this looks like a possible 1.4 feature for lock screen that will require interaction design recommendations.
Flags: needinfo?(rmacdonald)
Assignee: nobody → stephouillon

Comment 20

5 years ago
Removing the flag for UX since this feature is in Bruce's 1.4 backlog, and UX for this will be covered as part of that usual 1.4 work.
Flags: needinfo?(rmacdonald)
The user facing side of this feature will not make it to 1.4, keeping in backlog for now.
blocking-b2g: 1.4? → ---
With WebCrypto supporting now PBKDF2 (bug 1021607), it makes more sense to encrypt the password by using the crypto API. Integrating the changes for 2.2 would be made while moving the lockscreen to a separate app (bug 898348).

Some thoughts about UX:

Do we keep the 4-digits passcode option and add a new 'password' option in the lockscreen settings, or do we remove it? 
From the security perspective, it would be better to encourage people using a stronger password as much as possible. One main disadvantage of the current digits passcode is that it is very easy for other people to catch it when typing it in public.

Setting an alpha-numerical passcode requires to display the keyboard on the lockscreen and add a button "OK" to send the password. Because passwords won't have a fixed size anymore, it won't be possible to detect automatically when the user has finished entering 4 digits and validate it without having to push a button on the lockscreen. 

There is the same behavior when creating or modifying a password in the settings app, but it already has some button on the top right corner saying "create", "change", etc.
Flags: needinfo?(rmacdonald)
Although I would still recommend a simple 4 digit passcode as a default, I'm sure security-conscious users would appreciate this.

Bruce, I know this is in the backlog currently but let us know when you've committed to a release and we can put together a proposal.

- Rob
Flags: needinfo?(rmacdonald)
Hi Rob,
Let's explore this for 2.2.  I think that we can gradually add more unlock methods on top of this, for example we have options such as:
PIN (our original method)
Text (what the bug is addressing here)
Pattern
Face recognition
I would love having some kind of graphical password. 
Studies show it can be tricky to achieve a strong, secure and usable mechanism:
http://www.scs.carleton.ca/sites/default/files/TR-11-01%20Chiasson.pdf
http://cups.cs.cmu.edu/soups/2013/proceedings/a11_Schaub.pdf

I would be more careful about face recognition, having a strong implementation doesn't seem easy:
http://security.stackexchange.com/questions/43808/how-secure-is-androids-facial-recognition
blocking-b2g: --- → backlog

Comment 26

4 years ago
It is bit difficult to draw the patterns in the white screen. My suggestion is we can show the 9 small images and can ask the user to choose random image in a particular order. Here the main thing is user needs to remember the order. 

Then whenever logins we can show the different order for 9 images but the user needs to click on the images which he have choose(the order of the image will be constant but the position of the image will be different)

I have done a project based on this. Would like to share the paper which I worked soon.
(Assignee)

Updated

3 years ago
blocking-b2g: backlog → ---
tracking-b2g: --- → backlog
Assignee: stephouillon → nobody
Status: NEW → RESOLVED
Last Resolved: a year ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.