Seahorse integration

Camino is doing exactly this, a similar implementation could be used.

I like the idea of integrating the password manager with Gnome, but is it possible to make it so that any password manager application could be made to plug into Firefox's password management system? It would be nice to use Norton Password Manager on Windows, or whatever comercial program the user happens to like and have Firefox use it directly. This would be a good thing for integration with operating environments and other applications.

Now that the Login Manager rewrite has landed on trunk for Firefox 3, writing a module to implement this support should be much easier. Basically, someone needs to write a component implementing the nsILoginManagerStorage interfaces, and that component would interact with the Gnome Keyring as needed.

This interface is described here: http://mxr.mozilla.org/seamonkey/source/toolkit/components/passwordmgr/public/nsILoginManagerStorage.idl

This task isn't currently on my to-do list, but I'd be happy to help explain the Login Manager interaction if someone wants to take a shot at this.

One potential issue I'm seeing is that nsILoginManagerStorage makes synchronous requests, which will freeze the UI while Gnome Keyring is asking for the password.

I'm not completely sure, but I also have the feeling the OS X Keychain API blocks the calling thread while waiting for the password (SecKeychainFindInternetPassword). That would mean the same issue happens for the OS X implementation.

I'm going to work on this, feel free to contact me if you want to help.

Created an attachment (id=270527)
version 0.1

First version. There are some issues when used with the password manager, like asking to save password more that necessary, or not updating password if changed.

See the XXX for other things to improve. There is no caching involved, so there are round-trips to the gnome-keyring-daemon for every page containing a form, which could be bad for performances.

I can confirm the issue where the UI is frozen in case gnome-keyring daemon is asking for confirmation. I saw that this is also happening with Camino+Keychain, but that's less an issue on OS X as the window content is buffered, unlike on X11 where it is not refreshed if we move another window above (ok, that should not be the case when using a compositing window manager).

Created an attachment (id=270611)
version 0.2

Forgot to unregister the category, and fixed an unused variable warning.

This went low priority for me, feel free to take this over.

*** Bug 410674 has been marked as a duplicate of this bug. ***

Does GNOME keyring replace Firefox internal password manager?
If not, it should.

(In reply to comment #10)
> Does GNOME keyring replace Firefox internal password manager?

no

> If not, it should.

That's what this bug is about, but no one is working on it right now.

Exactly the same situation with some non-duped bugs I've filed.

This bug is not only firefox related. It's a core bug.

I agree, it should rather be toolkit related (password manager is in toolkit/components/passwordmgr), but there's no Toolkit/Password Manager component.

There's been much discussion on reorganizing Bugzilla (eg, the thread rooted at http://groups.google.com/group/mozilla.dev.planning/msg/5c973137356768b0). It's been deferred for a variety of reasons, but should eventually happen. In the meantime, it's understood that a number of components in Firefox are effectively in Toolkit, so it's not really an issue. [The code is, in fact, in /toolkit.]

(In reply to comment #1)
> Camino is doing exactly this, a similar implementation could be used.
>

That's a different bug, the mac only bug 106400.

*** Bug 435207 has been marked as a duplicate of this bug. ***

Created an attachment (id=336264)
Updated patch to compile against firefox 3

I've modified the patch lightly to get it to compile on Firefox 3.

Created an attachment (id=336498)
Fixes for interaction with form login

While testing the latest path, I noticed that it didn't properly store and retrieve passwords saved in forms. I've attached an updated patch that works for me.

There are some more things that could be improved about the code, but what are the steps to get this included in Firefox proper?

I have simple question: does this include migration?

The current code doesn't include any migration support.

I've uploaded an installable version of this extension to https://addons.mozilla.org/en-US/firefox/addon/8737 to enable more people to test out the integration. Hopefully, some people will be able to give some good feedback to improve it.

I've tried the extension.

When it's installed I'm unable to store passwords.
The prompt "Would you like firefox to remember this password" stays visible after I click on "save password". No passwords is added to my keyring.

How can I debug this?

What are you using to verify that the password was added to the keyring? If you return to the same page again, is the password automatically filled in? Are there any errors in the Tools -> Error Console page?

I get this exeption in the console:

Fel: uncaught exception: [Exception... "Component returned failure code: 0x80004005 (NS_ERROR_FAILURE) [nsILoginManagerStorage.addLogin]" nsresult: "0x80004005 (NS_ERROR_FAILURE)" location: "JS frame :: file:///usr/lib/xulrunner-1.9.0.1/components/nsLoginManager.js :: anonymous :: line 388" data: no]

The password I tried to add does not appear in firefox password list, nor in seahorse (g-k-m frontend).

Im using Ubuntu 8.04 with a keyring that is automatically unlocked on login.

(In reply to comment #19)
> There are some more things that could be improved about the code, but what are
> the steps to get this included in Firefox proper?

Hi Matt, thanks for your work on this. The steps would be to find someone to review this. There are instructions on http://developer.mozilla.org/en/Getting_your_patch_in_the_tree how to find the right reviewer.

Another more general question is to know if this should be part of Firefox or should live as an extension.

On a more technical side, is the issue raised in comment 4 still there? That would be nice to have it addressed (it may not be trivial, if the API has to change to get asynchronous).

I was a bit worried about performance (comment 6). It could be interesting to see how having the addon enabled can impact performance when browsing pages with passwords (https://wiki.mozilla.org/StandaloneTalos is one of the tool for measuring regressions). Caching could help if the performance is an issue.

The current patch implements nsILoginManagerStorage directly in C++. Another approach I thought about would be to wrap the low-level Gnome Keyring API in a C++ component and then implement nsILoginManagerStorage in JS. That should make things simpler for adding caching (if needed), managing preferences (keyring name is hardcoded right now for instance) or others. (https://wiki.mozilla.org/JSctypes could be useful here but I don't think it's ready yet)

I think I'd sort of like to see more experience with people using this as an extension, first. One of the things that I want to be cautious about is moving where we store things (mozStorage vs keyring/keychain) without compelling value... The pessimistic view here is that most users won't care, and it incurs code maintenance costs.

One variation that would also be interesting to pursue is leaving the password storage where it is now, but using the keyring/keychain for storing a decryption key (sort of like a master password). For users that don't want the annoyance of a master password (as we currently implement it), pulling a decryption key from a system DB that's secured with the user's *login credentials* would be an improvement.

(In reply to comment #25)
> I get this exeption in the console:

I've uploaded a new version of the extension that enables some logging to get extra information about your failure. You can see the extra logging by running firefox from a command line like "NSPR_LOG_MODULES=GnomeKeyringLog:5 firefox -no-remote"

You should see a message or two like:
-1211177280[805ca10]: GK_ENSURE_SUCCESS(2) failed

In the console, and that will help us figure out why you can't safe passwords.

Thanks for all the feedback. I'll keep an eye on performance problems. About the screen repaint issue, I just got prompted to allow access to the keyring and Firefox had no problem repainting in the background.

I was personally motivated to fix get the gnome-keyring integration out there because I wanted to reduce the number of unencrypted passwords on my drive. Since that's my main goal, I don't mind if this feature lives as an extension or as part of the standard packaging as long as I can use it =).

As for the relative value of the keyring integration, it's all about security (although something like your suggestion would have worked as well). The argument that "that most users won't care" should really be re-phrased to say "that most users won't care, until they sell their machine and the buyer uses their passwords left on disk". Leveraging something like gnome-keyring to get the password encryption for free seemed like a easy win for me (and Sylvain had done most of the work already).

(In reply to comment #27)
> One variation that would also be interesting to pursue is leaving the password
> storage where it is now, but using the keyring/keychain for storing a
> decryption key (sort of like a master password). For users that don't want the
> annoyance of a master password (as we currently implement it), pulling a
> decryption key from a system DB that's secured with the user's *login
> credentials* would be an improvement.

That seems a good way to go. At the time, I started writing an extension to store the master password in the Gnome Keyring (however I didn't finish it). The idea was to have an option when setting the master password like "Generate and store Master Password in Keyring". Then a component would set it automatically during startup.

(In reply to comment #28)
> You can see the extra logging by running
 firefox from a command line like "NSPR_LOG_MODULES=GnomeKeyringLog:5 firefox
> -no-remote"
>
> You should see a message or two like:
> -1211177280[805ca10]: GK_ENSURE_SUCCESS(2) failed
>
> In the console, and that will help us figure out why you can't safe passwords.

I just tried this on another computer and it worked without any errors.
However, the passwords are only visible in firefox, not seahorse. Is that correct?

(In reply to comment #31)
> However, the passwords are only visible in firefox, not seahorse. Is that
> correct?

That's because the passwords are stored in the 'default' keyring, and not the 'login' keyring. Apparently, Seahorse only shows the passwords in the 'login' keyring.

(In reply to comment #32)
> (In reply to comment #31)
> > However, the passwords are only visible in firefox, not seahorse. Is that
> > correct?
>
> That's because the passwords are stored in the 'default' keyring, and not the
> 'login' keyring. Apparently, Seahorse only shows the passwords in the 'login'
> keyring.

Ah, I see!

The entry may look nicer to the user in the sehorse password listing if the type GNOME_KEYRING_ITEM_NETWORK_PASSWORD is used. Also, the display name is currently set to "Mozilla keyring entry". It should probably be the url, or something like "User at http://hostname..."

Hello!

I've downloaded the patch and compiled it successfully under my 64-bit Ubuntu. After installation the extension is displayed by firefox as active extension.

I used the command from comment #28 but I don't see any log messages that might belong to the gnome keyring extension. The passwords are saved but I think they are saved by the firefox password manager, because I can't see them in seahorse, even after setting the keyring to 'login'.

Missed I something?
Thanks!

This feature is a win-win! How long should it take before I can see it as an extension?

Thanks

(In reply to comment #35)
> This feature is a win-win! How long should it take before I can see it as an
> extension?

Not very long: https://addons.mozilla.org/en-US/firefox/addon/8737 (see comment 22)

Hello !
I've installed the last 0.2 firefox plugin.
That doesn't seem to work.
I'm using firefox 3.0.5 on ubuntu 8.10.

 NSPR_LOG_MODULES=GnomeKeyringLog:5 firefox -no-remote
-1210722624[95d8638]: Num items: 0
-1210722624[95d8638]: Num items: 0
-1210722624[95d8638]: GK_ENSURE_SUCCESS(4) failed
-1210722624[95d8638]: Num items: 0
-1210722624[95d8638]: GK_ENSURE_SUCCESS(4) failed

Gnome doesn't ask me to authorize firefox to use gnome-keyring.
When I click on "Add Password" on the bar, that do nothing, I have to click on "never" or "not now" for see the bar disappear.

I've compiled it for Firefox 22 and it seems to work according a Gnome user point of view (but I don't know how to check if my passwords are well encrypted).

Did some Kwallet user try it ? And what will be next step to include this patch in future Firefox release ?

Adrien - here's some steps you can take:
* Does it apply/compile for mozilla-central? (`hg clone https://hg.mozilla.org/mozilla-central`, `cd mozilla-central`, [apply patch], `./mach build`)
* It still needs (at least) a review from a PSM peer. As far as I know, Kai is unavailable to do PSM reviews. Other peers are listed here: https://wiki.mozilla.org/Modules/All (search for "PSM")
* There are a few build config changes, so it should probably get a review from a build peer (search that same page for "build config" - it's the one related to Gecko)
* You might consider marking old patches obsolete in this bug just to clean it up

Ok, I've tried to clone mozilla-central, apply patch and compile, but it wasn't successful.

In fact, I wasn't able to apply the patch and so I've tried to apply manually the changes, but it was a little bit as black magic for me. That's why I've got this compilation error I think : https://pbin.adorsaz.ch/?1b5e8a6be1f8052f#oqW8wBbbIW+kqyleweKWkSlQOEzThNoSfxzaMVofCCY=

I'll attach my patch file, but it doesn't work and it certainly doesn't respect your standards.

Created attachment 780879
Modified patch to be applied to mozilla-central, but it won't compile

Adrien - if you're looking to continue development on this patch, you can see if someone in #developers (see https://wiki.mozilla.org/IRC ) might be able to help you with the compilation issues. At a glance, it looks like you need to add some #includes (specifically, #include "nsDirectoryServiceUtils.h" and maybe #include "nsIFile.h" in this case).

Created attachment 785385
Refreshed patch

This is a refreshed version of attachment 713868; the changes were fairly minimal as noted in comment 91 and comment 92. Besides adjusting a few rejections it was just a matter of importing nsIFile.h to get it working.

I've done some light testing on my box, adding and removing the master password as well as externally deleting it from the key-ring and it seems to work fine.

Adrien, if you want to pick this up you can start working using this patch; otherwise I'd be keen on finishing this myself as this is a feature I've been sorely missing.

(In reply to David Keeler (:keeler) from comment #89)
> * It still needs (at least) a review from a PSM peer. As far as I know, Kai
> is unavailable to do PSM reviews. Other peers are listed here:
> https://wiki.mozilla.org/Modules/All (search for "PSM")

I am the PSM module owner but I am not even a peer in the toolkit or Firefox modules where the password manager lives. I am very interested in removing all the master password prompts on all platforms.

I know very little about Linux compared to most of the people CC'd on this bug; please be patient with me if I say something stupid.

1) I see in the patch that this is a build option that is off by default. I would prefer it to be ON by default for all Linux desktop builds, and if libsecret isn't available at runtime, then we just don't use it and we disable the Firefox UI related to the Gnome Keyring. Is there anything inherently wrong with doing it this way?

2) The patch contains a prompt that asks "Do you want to save master password to system password manager?" But, this seems like the wrong question. I think, instead, the "Change Password" dialog box should look something like this:

    (*) Protect my data with my system password (recommended)
    ( ) Use a master password:
        New Password: [ ]
        Confirm Password: [ ]
    ( ) Don't protect my data

If we did it this way, then we wouldn't need that separate prompt. Also, this UI would work for all operating systems, AFAICT. (Note: I am not a UX person and in theory a UX person should design the UI for this. However, this may get blocked for a long time if we wait for a UX person to design it, so I suggest you build a prototype UI and have the UX people review it. If it works well on Linux then we could port the same UI to other platforms.)

3) The Gnome keyring should never store/protect a password that the user entered. Instead, it should store a randomly-generated key (e.g. 32 bytes of randomness from nsIRandomGenerator, or similar). NSS's protection of the master password is very weak, and also users will almost always choose relatively weak passwords, so using a random key as the NSS password is important.

4) Some people at Mozilla are working on this "Sign into the browser" / "Profile in the Cloud" thing, of which Sync is a part. See https://wiki.mozilla.org/Identity/AttachedServices. I think it is important to make sure that the people working on this feature discuss it with the the Identity people to make sure that this work and that work is compatible/complementary.

(In reply to Brian Smith (:briansmith), was <email address hidden> (:bsmith) from comment #94)
> 2) The patch contains a prompt that asks "Do you want to save master
> password to system password manager?" But, this seems like the wrong
> question. I think, instead, the "Change Password" dialog box should look
> something like this:
>
> (*) Protect my data with my system password (recommended)
> ( ) Use a master password:
> New Password: [ ]
> Confirm Password: [ ]
> ( ) Don't protect my data
>
> If we did it this way, then we wouldn't need that separate prompt.

Now, let me argue against myself.

Shouldn't the users that care about protecting their passwords be using full-disk encryption with a system password already? Why don't we just remove the master password mechanism on Linux completely, and rely on users use of operating-system-level protection of their whole profile? That is, wouldn't the best UI be this?:

      Mozilla recommends that you use a system password
      and full-disk encryption to protect your data; if
      you do that, then a master password is not very
      helpful. We still support using a master password
      for now, but we highly recommend against using
      one, and we may remove this misfeature in a
      future version.

      [ ] Use a master password:
          New Password: [ ]
          Confirm Password: [ ]

(In reply to Brian Smith (:briansmith), was <email address hidden> (:bsmith) from comment #95)
> Shouldn't the users that care about protecting their passwords be using
> full-disk encryption with a system password already? Why don't we just
> remove the master password mechanism on Linux completely, and rely on users
> use of operating-system-level protection of their whole profile?

Full-disk encryption won't be available to whoever is storing its data on a computer he/she doesn't control. For example you might have to keep your profile on a shared drive when working in an office (alas that's a situation I have been in multiple times) and for those use cases providing a way to encrypt your saved passwords is very important.

(In reply to Brian Smith (:briansmith), was <email address hidden> (:bsmith) from comment #94)
> 1) I see in the patch that this is a build option that is off by default. I
> would prefer it to be ON by default for all Linux desktop builds, and if
> libsecret isn't available at runtime, then we just don't use it and we
> disable the Firefox UI related to the Gnome Keyring. Is there anything
> inherently wrong with doing it this way?

It shouldn't be a problem if we can dynamically load the library at runtime.

> 3) The Gnome keyring should never store/protect a password that the user
> entered. Instead, it should store a randomly-generated key (e.g. 32 bytes of
> randomness from nsIRandomGenerator, or similar). NSS's protection of the
> master password is very weak, and also users will almost always choose
> relatively weak passwords, so using a random key as the NSS password is
> important.

This has a drawback however: if for some reason you lose your keyring then you loose all your saved passwords. It also means that you can't move your profile across machines unless you also move the keyring (or write down the random-generated password). If the master password by itself is week wouldn't it be better to generate a random salt and store it in plain-text in the profile and then use the master password + salt for the encryption? That would improve the effectiveness of the resulting encryption while keeping a password that cannot be remembered by the user. Would there be any downsides to doing it this way?

What are the downsides of completely relying on libsecret for storing passwords instead of a proprietary solution? Then a user had all his passwords in his keyring and wouldn't have to care about other locations where passwords are stored.

(In reply to Brian Smith (:briansmith), was <email address hidden> (:bsmith) from comment #94)
> 4) Some people at Mozilla are working on this "Sign into the browser" /
> "Profile in the Cloud" thing, of which Sync is a part. See
> https://wiki.mozilla.org/Identity/AttachedServices. I think it is important
> to make sure that the people working on this feature discuss it with the the
> Identity people to make sure that this work and that work is
> compatible/complementary.
AFAIK this has nothing to do with master password. Master password is not send to Sync service and user is not required to set master password on other Firefox instances, but it's good to keep Sync in mind.

(In reply to MartinSchroeder from comment #98)
> What are the downsides of completely relying on libsecret for storing
> passwords instead of a proprietary solution? Then a user had all his
> passwords in his keyring and wouldn't have to care about other locations
> where passwords are stored.
This is also an option but it requires more libsecret binding:
Getting list of passwords for Saved Passwords dialog and allow to remove individual records if we want to keep Saved Passwords and Sync working.

Personally I would stay with currently easiest solution which is storing user defined master password to libsecret's keyring. It's up to user to set strong password for Firefox and Keyring. They have probably weak password now because they have to retype it frequently. If they didn't have to they would eventually set stronger password. It's also smaller change to introduce new bugs since we're doing lesser change.

(In reply to Brian Smith (:briansmith), was <email address hidden> (:bsmith) from comment #94)
> The Gnome keyring should never store/protect a password that the user
> entered. Instead, it should store a randomly-generated key

Agreed that it feels unnatural to have to define a master password when you are using the native keyring. But bear in mind that the whole approach of continuing to use proprietary password storage, and keeping only a single decryption key in the native keyring, is unnatural to users and has the sole merit (I presume) of requiring fewer code changes. Proper integration means storing all passwords as regular entries in the native (login) keyring, where they can be inspected and even edited using standard tools like seahorse. This is what Chrome seems to do, and what you would expect any polite application to do.

(In reply to Jesse Glick from comment #100)
> Agreed that it feels unnatural to have to define a master password when you
> are using the native keyring. But bear in mind that the whole approach of
> continuing to use proprietary password storage, and keeping only a single
> decryption key in the native keyring, is unnatural to users and has the sole
> merit (I presume) of requiring fewer code changes. Proper integration means
> storing all passwords as regular entries in the native (login) keyring,
> where they can be inspected and even edited using standard tools like
> seahorse. This is what Chrome seems to do, and what you would expect any
> polite application to do.

Let's please tone down the rhetoric regarding "proprietary" a little bit. The Gnome keyring is no less proprietary than any part of Firefox is.

I am not opposed to Firefox doing what you suggest if it isn't problematic to do so. But, please explain how a user would switch from Linux to Windows and bring their passwords with them; then please explain how a user would switch from Windows to Linux and get their passwords in the Gnome keystore. Right now a Firefox user can just copy their profile directory over to the new platform and they're done. With the "random master password" mechanism, they would have to first change from the random password to a user-entered password before copying the profile files over. With the "all passwords stored in the OS keyring directly" approach...I am not sure; help me understand what would happen.

Also, syncing of passwords across devices is a must-have requirement. So, any solution for this bug must support Firefox Sync, and must not complicate the implementation of the upcoming improvements to Firefox Sync.

> explain how a user would switch from Linux to Windows and bring their passwords with them

Same way you would for secrets used by any other application: enter them again. This is an OS/desktop issue, not the responsibility of an individual application. Of course if you have decided to use cloud password storage like Sync then that would be your means of sharing secrets across machines.

By the way Windows seems to have no general service comparable to GNOME Keyring or KDE Wallet or OS X Keychain. It does have CryptProtectData, meaning that on Windows it is appropriate for Firefox to store its own passwords so long as it uses this API to prevent them from being kept on disk in cleartext.

Sorry for introducing the "proprietary" term. I didn't assign any judgement to it.

Wouldn't it be optimal, if Sync would be able to store and load into and from a file? Then the data could be brought everywhere without storing it online. This way the differences between systems wouldn't matter.

(In reply to Jesse Glick from comment #102)
> > explain how a user would switch from Linux to Windows and bring their passwords with them
>
> Same way you would for secrets used by any other application: enter them
> again. This is an OS/desktop issue, not the responsibility of an individual
> application. Of course if you have decided to use cloud password storage
> like Sync then that would be your means of sharing secrets across machines.

Why not make it still possible? I see no benefit in retyping password when copying profiles. IMO profile should contain all data user wants it to store (ie. also list of passwords). Anyway do the libsecret supports KDE right now? If it doesn't we could probably cut password store support by this change for KDE users or implement another kwalletd backend.

I think storing master password in system keyring manager is making things more loosely coupling. In case system keyring manager doesn't provide master password then we fallback to user input of master password. In case we saved all passwords to keyring and for some reason keyring won't be available users wouldn't have a change to have they passwords pre-filled.

(In reply to jhorak from comment #104)
> do the libsecret supports KDE right now?

https://wiki.gnome.org/Libsecret says it does.

(In reply to Jesse Glick from comment #105)
> (In reply to jhorak from comment #104)
> > do the libsecret supports KDE right now?
>
> https://wiki.gnome.org/Libsecret says it does.

The site says that libsecret supports ksecretservice. And ksecretservice is not working very well and is not included by default (AFAIK).

But what is the problem with using libsecret under Gnome and Firefox' own storage under KDE? Then it's like before under KDE until they have a freedesktop.org compatible key storage.

Hey guys, just wanted to give a heads up here...

I gave a talk at GUADEC which presented an alternate password storage model, where the secret service provides a master key to apps (like firefox) via standard interfaces like the linux kernel keyring. Apps can use this key to encrypt their own password storage database.

The above works well in the case of sandboxing. I think it also fits really well within the firefox model. You don't have to worry about things like async access for each password to another daemon.

I feel bad posting this here without more details, but over the next few days I'm going to clean up my slides, and do some blog posts about this.

You can see a bit of history here:

http://lists.freedesktop.org/archives/authentication/2013-May/000267.html

I think we have to differenciate between two levels:
- The ability to *securely* store passwords (with a master password or a key provided by the system's key manager)
- The ability to securely *store passwords in the system's key manager*, where all my passwords live.

I favor the second option. I'm not concerned about moving passwords between different systems (that should happen rarely). And if I happen to use multiple devices: That's what Sync is for.
I am concerned about storing my passwords in a way that I trust: my system's key ring (storing keys is it's only purpose and I think it should be good at it).

Of course the thoughts in the link posted above[1] are also good ones.

[1]
http://lists.freedesktop.org/archives/authentication/2013-May/000267.html

Okay, it seems that we're moving in circles. Who's going to decide which approach to choice? I can implement storing password to system keyrings but I won't do this without clear statement from Mozilla what they would like more. I still prefer storing only master password because of loose coupling.

Created attachment 790711
Refreshed patch

(In reply to jhorak from comment #109)
> Okay, it seems that we're moving in circles. Who's going to decide which
> approach to choice? I can implement storing password to system keyrings but
> I won't do this without clear statement from Mozilla what they would like
> more. I still prefer storing only master password because of loose coupling.

I am also in favor of storing the master password in the keyring as it seems the less intrusive approach and the most likely to land soon. It might not be a perfect solution but it improves the usability of the master password a lot. Besides once the harness is in place it will be easier to change the behavior (to store a random password, add a salt or whatever else). The only thing that we might want to change compared with the existing patch (of which I'm reattaching a refreshed version again) is probably in the UI part where we probably want the option to be shown in the same dialog as the master password instead of on a separate pop-up.

I've looked at the password manager log and it seems to me that Justin Dolske comes up often both as a contributor and a reviewer so I'm needinfo'ing him here as he's both a Firefox and Toolkit peer in the hope he's the right person to ask. Justin could you have a look at the approach we're taking here or point us to someone who could help out with this?

Regarding the UI: If you go with the master password option (for now if not permanently), I would suggest adding two features to the Master Password dialogue: a checkbox to store the password in the user’s key{ring|chain}, and a button to generate a random password. The button would lead to an additional UI, which would include a checkbox to toggle showing the password. The “show password” box would default to the logical inverse of state of the “store in my key*” box (since it makes no sense to generate a random password and then neither store it nor show it).

Does this sound reasonable?

(In reply to David Webb from comment #111)
> Does this sound reasonable?

Yes, it sounds like a good idea but also material for a follow-up. Let's open a separate bug for that so that we don't make the patch here too large or we'll never be done with it :)

(In reply to Gabriele Svelto [:gsvelto] from comment #110)

> I've looked at the password manager log and it seems to me that Justin
> Dolske comes up often both as a contributor and a reviewer so I'm
> needinfo'ing him here as he's both a Firefox and Toolkit peer in the hope
> he's the right person to ask. Justin could you have a look at the approach
> we're taking here or point us to someone who could help out with this?

It's a NSS/PSM patch, so that would be Brian Smith. But I'd have some of the same concerns he's noted in previous comments.

In general, I'd say that (1) the existing master password stuff is a giant mess that doesn't address modern threat models (2) we shouldn't pile more onto that shaky foundation and (3) neither the master password nor extensible nsILoginManagerStorage interface are very successful features.

So, I don't think we should invest time into supporting this, and it would be better implemented as an add-on for those who want it. Sorry. :/

(In reply to Justin Dolske [:Dolske] from comment #113)
> So, I don't think we should invest time into supporting this, and it would
> be better implemented as an add-on for those who want it. Sorry. :/

This HAS been implemented as an addon: https://github.com/infinity0/mozilla-gnome-keyring

The problem is that it has to be a binary add-on and is therefor next to impossible to maintain with Firefox' rapid release cycle. Some Linux distributions don't even ship Firefox development headers anymore, and comment it with "this should be integrated into Firefox, please contact upstream".

This is a pledge from a user: PLEASE integrate this patch. This is functionality that is wanted and needed (since the Master-password stuff is indeed a giant mess) by a lot of people and you even have a patch provided and people willing to maintain it.

(In reply to Alexander Korsunsky from comment #114)
> This HAS been implemented as an addon:
> https://github.com/infinity0/mozilla-gnome-keyring
>
> The problem is that it has to be a binary add-on (...)

This isn't true. jsctypes can be used to call whatever APIs the binary addon uses.

> So, I don't think we should invest time into supporting this, and it would
> be better implemented as an add-on for those who want it. Sorry. :/

I would have thought you should invest time on what matters to users. This feature has a fair amount of votes and the absence of this feature is one of the most obvious and annoying thing on Firefox compared to Chrome: I am sure many users have had to type their master password thousands of times so far because of this. Also this is my own opinion, but I find this popup _soooo_ annoying.

Also, were there an up-to-date add-on, I would not trust it as much as if it was built-in. Such security features should be built-in IMO.

Investing time is always a tradeoff. I have a long list of projects to dramatically improve Firefox for users, and unfortunately the feature this bug about ranks poorly against that list. The number of users using a master password and linux is relatively tiny, and there are number hurdles to even making this a feature suitable to ship (see Brain's previous posts for a few). That's why an add-on is the right route to take.

I don't know much about the internal workings of the Firefox Project, but I'm willing to bet that those people using Linux AND using a master password AND Firefox are of a demographic that would be resistant to sending anonymous usage data.

(In reply to Justin Dolske [:Dolske] from comment #117)
> Investing time is always a tradeoff. I have a long list of projects to
> dramatically improve Firefox for users, and unfortunately the feature this
> bug about ranks poorly against that list. The number of users using a master
> password and linux is relatively tiny, and there are number hurdles to even
> making this a feature suitable to ship (see Brain's previous posts for a
> few). That's why an add-on is the right route to take.

You made a wrong assumption. This feature is not only for master password users. I don't use it be cause it is stupid. I have a session password on my OS, and I expect it to protect everything else. I don't want to have thousands of passwords to manually keep in a text file or a third party keayring software.
The master password and the lack of native keyring support are 2 reasons leading me to switch to Chrome on all of my non-home or mobile devices.
On my Ubuntu home desktop, I tried to use an encrypted home dir, but FF is using I/O too much, so it was too slow and laggy.
The most secure is my MacBook Pro whose disk is fully encrypted and whose web browser (Chrome) is using keyring.

Using the keyring is exactly what I expect from ANY application, thus Firefox, that need a secret key to protect data without pissing me off with one more password. This is a seamless solution for every non-technical, IT-ignorant user. Those user are not using master password, so keyring would be a great solution to add protection without increasing complexity.

I know that there is some technical challenges to add keyring stuff to FF, but whining is not a solution, and believing there is more important UX stuff to do before is an error. This is a security concern, perhaps the #1 security concern in FF. Or if you prefer being troll-flammed by newpapers (http://www.theguardian.com/technology/2013/aug/07/google-chrome-password-security-flaw)...

I have not the C/C++ skills and the FF code base knowledge to help you so I can only encourage you and critisize reluctant attitudes that are legions in Mozilla organization (and sometime at a high hierarchy level... I had a bad experience with Tristant Nitot leading a big French bank switching from IE6 to IE8 instead of FF).

Please get into the future with implementing the keyring. Future is not only HTML5/CSS3 and Co.

(In reply to Justin Dolske [:Dolske] from comment #117)
> Investing time is always a tradeoff. I have a long list of projects to
> dramatically improve Firefox for users, and unfortunately the feature this
> bug about ranks poorly against that list. The number of users using a master
> password and linux is relatively tiny, and there are number hurdles to even
> making this a feature suitable to ship (see Brain's previous posts for a
> few). That's why an add-on is the right route to take.

Applications should always make security easy. If a user has already taken the step of selecting an OS with a keyring function, FF should honor her decision and use that keyring, without extra steps required.

FF has been a keystone of exposing users to the quality that the open-source ecosystem can create. It's THE default browser of the most popular GNU operating systems. I'm not a developer (yet), and I can't make these changes myself (yet), I can't force anyone else to, and I greatly appreciate the time that has gone into making FF what it is. But if we want FF to continue to be the foundation of the FOSS ecosystem that it has become, then it should make security easy. As is, users have these choices:

* install an addon ("Why doesn't this software come with essential features already installed?")
* use a master password ("Another password? I just made a system password!")
* do nothing and use the password store w/out master password (user thinks she is secure; she isn't)
* copy/paste from the system keyring or another software (like an addon, only less convenient)
* disable password storage altogether and use sticky notes on the monitor

The default browser on Mac OS already provides a secure, convenient password experience. The default browser in Ubuntu, on the other hand, doesn't reach the bar set by many FOSS projects in leveraging *existing* tools, waiting to be used, instead re-inventing the wheel and forcing redundant user actions.

GNU operating systems are trying to reach out to less-technical users. Firefox should help these efforts by at least meeting the standard of security set by the competition, as a standard feature. Not as an addon.

Is there any update/ongoing work on this?

There are several attacks out in the wild that allow extracting passwords from the firefox store. As it has been said before, non-technical users will not use the master password (I don't use it either because it bugs me with yet another password prompt). Implementing this would be a major step forward in improving users' security.

(In reply to Mike Hommey [:glandium] from comment #115)
> (In reply to Alexander Korsunsky from comment #114)
> > This HAS been implemented as an addon:
> > https://github.com/infinity0/mozilla-gnome-keyring
> >
> > The problem is that it has to be a binary add-on (...)
>
> This isn't true. jsctypes can be used to call whatever APIs the binary addon
> uses.

And just which javascript api has access to my gnome keyring? God willing, none! If there is a hope in hell for this thing to be secure, it can't be done in javascript. So, yeah. It has to be a binary plugin.

(In reply to Eric Toombs from comment #122)

You should give https://developer.mozilla.org/en-US/docs/Mozilla/js-ctypes a read - JS used in Firefox add-ons is privileged and can use JS-ctypes to interact with system libraries.

In response to claims of Chrome's superior password management, I just lived through a use case where keeping the browser's passwords decoupled from the system is much easier to work with.

Short version: Changing Linux distros broke Chromium's access to my saved passwords. Please don't introduce such a fragile dependency in Firefox. I don't want to be locked in to my current OS just to keep using the same cross-platform browser.

Long version:

I had been using Chromium on Chakra Linux for a few years. Chakra is a "half-rolling" distro built around KDE, so it gets the latest KDE stuff faster than most other distros. Then I lived somewhere with metered Internet access for a couple months, so I switched to Firefox, using the lazy tab loading on start-up to reduce bandwidth use.

(off topic: It was really annoying manually importing passwords to Firefox since it doesn't have the feature. I miss Chrome's process-per-tab model that keeps the rest of the browser fast when one tab is busy. At least NoScript mostly keeps tabs from getting too busy in the first place. Also Firefox's Tree Style Tab add-on makes it much easier to keep a zillion tabs organized.)

Now that I'm living somewhere with unmetered Internet again, I've decided it's about time to do some distro-hopping and see how things have changed. Switching between various distros and desktop environments/window managers, Firefox has consistently given me access to my passwords via the master password, even when Firefox's version got shuffled back and forth.

Eventually, I ended up settling on OpenSUSE 13.1 using KDE, but apparently with a slightly older and incompatible version of kwallet. I just opened Chromium for the first time since July. Since all my log-ins have expired, it wants to access saved passwords. However, despite using the same browser and desktop environment I had been in July, with both within a year of the other, Chromium cannot access my saved passwords. I'm stuck with kwallet giving me an "Error code -4: Unsupported file format revision" message. So much for Chromium. Maybe it'll work again on OpenSUSE 13.2 in a couple months?

I guess I'll use Chromium for all the complicated "web 2.0" stuff that Firefox's single process chokes on. Firefox still seems best for not randomly losing abilities and for being widely extensible.

(In reply to Mike Hommey [:glandium] (out from Sep 6 to Sep 22) from comment #115)
> (In reply to Alexander Korsunsky from comment #114)
> > This HAS been implemented as an addon:
> > https://github.com/infinity0/mozilla-gnome-keyring
> >
> > The problem is that it has to be a binary add-on (...)
>
> This isn't true. jsctypes can be used to call whatever APIs the binary addon
> uses.

Right, and this has been implemented as a pure JavaScript addon:
https://github.com/swick/moz-gnome-keyring-integration

Note that https://bugzilla.mozilla.org/show_bug.cgi?id=106400 is the counterpart for Mac OS X. It has a little under twice the votes and twice the age of this bug. Any work on one of these bugs would likely benefit the other. Maybe there should be an OS-neutral metabug for the two?