User Agent: Mozilla/5.0 (X11; Ubuntu; Linux i686; rv:20.0) Gecko/20100101 Firefox/20.0 (Beta/Release) Build ID: 20130417085616 Steps to reproduce: I just had a quick look how secure the passcode protection of my new Geeksphone Peak is and found that I don't need to have the passcode to unlock it. We can just connect any microUSB cable that is arround and display the 4digit passcode on screen. This is a *huge* security bug. Android and other OS have/had also problems w/ those lockscreens/pattern etc but most algos at least hash (w/ a "secure" algo like PBKDF2) the code using long salts and many iterations. Remote Debugging must be enabled for this to work, which is very likely on a developer phone (like PEAK and Kean)... Actual results: The passcode is unprotected, serialized (in *PLAIN* text) to database, and accessible via ADB (or maybe also other remote connections). Expected results: No plain test passcode should be arround at all. It should be hashed immediately and removed saftely from phones memory (RAM) too. One should compare hashes instead of plains. Sensitive data should be on this indexeddb databases at all... I see there also some wifi wpa passcodes etc. Only root user should be allowed to access sensitive files at all (see also wpa_supplicant configs) and adb shell should also have a mechanism to disallow connections if we have passcode protection enabled. I think this bug also qualifies for a bug bounty, since: - bug is is new, original and previously unreported - it is kind of a remote exploit since the passcode can be gathered via the remote debugging interface (ADB), indeed we do not have to have access to the device at all. The device must of course connected via USB or other means - I am not the author of the buggy code nor otherwise involved in its contribution to the Mozilla project - I am *not* an employee of the Mozilla Foundation

This is a dupe of 805256 amongst others, and not unexpected behavior for developer phone devices. Remote debugging is disabled by default for this reason - see duped bug for further discussion.

I don't think that this is a duplicate of what you linked. I carefully read the other bug, there is no mention of the indexeddb, hashes, passcodes, salting, iteration etc at all. I see what you mean of what only root should be able to do, but should the root user get the passcode in plain text? This is a bad joke, isn't it? In my humble opinion, neither a normal user, *nor* the root user should see passwords if not neccessary needed. Why does FirefoxOs need to *store* the plain passcodes? Why it does *not* use a hashing scheme (like other modern os do)... This sqlite database reading is indeed also a bug if the other bug was fixed... There should be no passcode plains at all. Please re-open PS. Another discussion is of course why do not allow passphrases (w/ text included etc)... but that of course is a feature request rather than a huge security problem.

Reopened bugs should not be summarily re-closed without comment. Comment 2 makes the case that this bug is different (more) than bug 805256 and I don't see any refutation of those claims. The remaining issues are also known design choices for the first version of the phone (the inability to set more than a 4 digit lock code in particular is a large source of grumbling), but if there aren't actual bugs filed on them this might as well be the one. The recent mailing list discussion "Global Accounts Management in FirefoxOS" envisions some kind of keychain-like service https://groups.google.com/forum/?hl=en&fromgroups#!topic/mozilla.dev.gaia/0YXCmyVrIFo It's also known that global settings are shared too widely, pretty much with every application (bug 841071 and earlier bug 763965; bug 846200 is filed as a future improvement). The password issue was explicitly noted in bug 817206, but wontfixed apparently on the claim that requiring root is good enough. If anyone is going to close this bug as a duplicate again then bug 817206 is a better match. Do we want to reconsider that decision? Is that where the dev-gaia thread is headed anyway (for a future version of the device)?

This bug will probably end up duped (or "depends on") the eventual keychain-like feature, but that was planned for a later version of the device.

Note that this will likely be fixed as part of adding support for longer passwords/codes in bug 877541. The approach in the WIP patch is to provide a passcode hashing service to content.

Jonas: Gregor and I thought you might want to be looped in on this bug as it is a pretty bad situation. The fix is being discussed in bug 877541

So if you have root access, and if the passcode is stored with a known hashing/salting algorithim, then I could also just replace the passcode salt/hash in the indexedDB with a known hash, and restore the original one later on. So, at least if you have root access, even if the passcode was salted/hashed, it wouldn't make things any more secure.

Forget what was said in comment #8. Secrets (including passwords, passcodes, ...) primarily goal is to keep them *secure* and to use them as a safe method for logins, authentications, etc. If those secrets are not hashed w/ a method currently known as *secure* (PBKDF2, bcrypt... not too many unfortunately), they miss there goal to be "protected" and only known to the owner of the passwords (that implies, not even known to the phone/computer etc itself). This has nothing to do wheter we are root or not root user. Believe me and thousands of security experts and cryptographs etc... hashes are not totally useless as Dave (comment 8) suggests. Counterquestions: why should popular CMS store passwords *only* in hashed form, when the attacker/intruder could also change the admins hash? SAME and identical reason. Secrets are there to be protected. And even if one could theoretically swap the hash w/ a newly-generated one (which also should be made difficult/impossible to do, but this is another topic), the "attacker" would not know your secret if, and only if, it was hashed. There are still ppl that use their passcodes/passwords for many sites/phones/services etc... an attacker could use your plain text passwords (if not hashed) to steal your information etc by logging in with that FF OS phones plain password into the other site/phone/service etc. I just want to make this things clear; ... and this necessary "feature" of hashing passcodes whould be just the very first step to make FF OS a little bit more secure. Other (mobile) OS (including Android) do such things already from their beginning (but honestly, they had had also some problems in doing so). I would suggest that this very important and "sensible" topic of making FF OS secure should be done, or at least designed and overseen, by a person that has cryptographic background (otherwise silly mistakes as recently discovered for cryptocat etc are very easy to make and won't be discovered easily). Furthermore there exist(ed) also some examples of bypassing e.g. Android lockscreens etc... this is something that FF OS should avoid too ... again this needs to be designed/programmed/tested etc by ppl w/ backgrounds in secrurity/cryptography etc. Also, you have to think if e.g. for some ppl here a phone's password "leak" is considered as a minor thing (at least this is my impression if I review the above comments/replies), there are and could be more and more ppl whose privacy (maybe also their overall freedom/life) is at risk just because FF OS doesn't use what cryptographs/security experts recommend - since years - (but instead FF OS does nothing, or sometimes even worse, try to use something else, home-made).

Just to be clear, I'm in total agreement with using hashed passwords. I'm just pointing out that once you have root access, it doesn't matter whether the pin-code are hashed or not. In this case (having root access), having the password hashed prevents you from determing the pin-code, but won't prevent you from unlocking the phone. With root access, I could also just modify the code that checks the pin-code and make it always pass the test.

I have started this in bug 1100945 and resolved a few issues with it in bug 1126779. Follow-up bugs will make sure that all existing lockscreen code uses the Helper library. Please follow bug 1100943 for more. Phillipp: Again, thank you for reporting this. Feel free to look at those bugs (actually, just the latter two), if you want to take part in fixing this! You can also reach me during CET working hours on IRC.