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

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

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.

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.

Fixed a minor mistake

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

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

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

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?

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.

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

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.

forgot hg add

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.

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

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

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.

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

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

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.

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

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.

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

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

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.