877541 - Support stronger password in lockscreen

Status: RESOLVED WONTFIX

(Firefox OS Graveyard :: Gaia::System::Lockscreen, defect)

Description

[Paul Theriault [:pauljt] (no longer reading bugmail)]

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

Comment 1

[Paul Theriault [:pauljt] (no longer reading bugmail)]

This is an important feature because without it we are limiting the security choices of our users. Nominating for koi.

Comment 2

[David Dahl :ddahl]

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

Comment 3

[David Dahl :ddahl]

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.

Comment 4

[David Dahl :ddahl]

Attachment: Backend WIP patch

Fixed a minor mistake

Comment 5

[Paul Theriault [:pauljt] (no longer reading bugmail)]

I'm sure exactly who owns the lockscreen frontend - maybe Tim? Or Tim I assume might know who does if it isn't you?

Comment 6

[Tim Guan-tin Chien [:timdream] (please needinfo)]

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

Comment 7

[David Dahl :ddahl]

(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

[David Dahl :ddahl]

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?

Comment 9

[David Dahl :ddahl]

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

Comment 10

[Gregor Wagner [:gwagner]]

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.

Comment 11

[David Dahl :ddahl]

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

Comment 12

[David Dahl :ddahl]

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

Comment 13

[David Dahl :ddahl]

Attachment: Patch 1: SettingsHash.jsm

forgot hg add

Comment 14

[David Dahl :ddahl]

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.

Comment 15

[Tim Guan-tin Chien [:timdream] (please needinfo)]

Push this to v1.3 since v1.2 has been feature frozen.

Comment 16

[Bruce Huang [:bhuang] (inactive)]

Moving to backlog for now.
ni to Paul if there are more updates as per Comment 14.

Comment 17

[Paul Theriault [:pauljt] (no longer reading bugmail)]

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.

Comment 18

[Bruce Huang [:bhuang] (inactive)]

Moving out of 1.3 as it looks to be a fairly large amount of work.

Comment 19

[Stephany Wilkes]

Flagging Rob as this looks like a possible 1.4 feature for lock screen that will require interaction design recommendations.

Comment 20

[Stephany Wilkes]

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.

Comment 21

[Bruce Huang [:bhuang] (inactive)]

The user facing side of this feature will not make it to 1.4, keeping in backlog for now.

Comment 22

[Stephanie Ouillon [:arroway] (needinfo me)]

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.

Comment 23

[Rob MacDonald [:robmac]]

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

Comment 24

[Bruce Huang [:bhuang] (inactive)]

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

Comment 25

[Stephanie Ouillon [:arroway] (needinfo me)]

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

Comment 26

[Viswaprasath [:VP7]]

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.