Implement workspaces/identities

[palant]

It should be possible to separate your private and work passwords for example. In some cases it might also be necessary for multiple people to use the same PfP instance. This should be possible by separating PfP data into multiple distinct workspaces/identities. Each workspace will have its own master password, which might be identical to other's but doesn't have to be. They should also have their own set of passwords, their own sync settings and their own shares. The actual implementation plan:

• A new key workspaces is added to storage, listing workspaces with name and numerical ID. Workspace IDs should be random rather than sequential, so that conclusions about deleted workspaces aren't possible. The data isn't encrypted (cannot be, because workspace information has to be retrieved before master password entry).
• A new key current_workspace indicates the last used (current) workspace. Its data is also unencrypted.
• All other storage keys are prefixed with <workspace_id>: meaning that they are bound to their respective workspace.
• Initially, a single workspace with a random ID and name "Default" is created. It becomes the current workspace.
• The master password entry gets a workspace selector. Initially, it displays the current workspace. Clicking it gets you to the workspace list where you can select a different workspace, rename or remove workspaces and create a new workspace.
• Once you enter your master password, the workspace is fixed and all operations apply to it. Changing your workspace requires locking the passwords.
• Creating a new workspace will ask for a name and bring you to the "set master password" page then. It also makes the new workspace the "current" one.

[adrium]

Hi Wladimir,

First of all, thanks for that great tool! It really seems like the optimal password manager! I particularly like the hybrid approach.

+1 for this issue. However, I only need to have several master passwords for increased security.

By looking over the implementation, I think this could be implemented without much work by including the master password's hash in the storage prefix. When changing the master password, do not delete anything, but simply change the prefix.

-1 for the identities idea... I think it might complicate the storage unnecessarily. Identity management is already implemented in Chrome and Firefox. I think the approach above is sufficient. If really multiple users use the same instance, they should be seperated by a different master password.

[palant]

The storage format changes are really the trivial part here. Replacing storage IDs by master password hashes isn't going to make it much simpler. However, it will make your data less discoverable - you might have data for a different master password in there, and you won't even know unless you still remember that password.

Identity management implemented in Chrome and Firefox can already be used to achieve the same effect. In reality, most people won't do it however because the implications go far beyond PfP - different identities have different sets of extensions for example. In addition, creating a new Firefox profile is far from trivial which means that this feature is barely used. Even for Chrome it is considered an advanced feature.

[adrium]

I just migrated my passwords at work and the usage of the tool is really pain-free. :blush: (Although the choice of the font-size is more oriented towards sight-impaired people...) :see_no_evil:

However, to be usable for my private accounts, I need to be able to use multiple master passwords. Can you perhaps implement this feature in two steps?

storage format changes are really the trivial part here

Then it would be nice, if you could implement this as a first step.

However, it will make your data less discoverable - you might have data for a different master password in there, and you won't even know unless you still remember that password

Clearing the storage is simple by invoking the clear() method.

Concerning discoverability: I think that's fine... You could even advertise it as a security by obsurity feature! :sweat_smile: Otherwise, you could store a global key with the list of used master passwords in the store. This list could even include the starting letter of the password or a user-defined hint, if desired, like:

[
  { "hash": "1234", "letters": "te" },
  { "hash": "abcd", "hint": "Sweet cherries" }
]

[Identity management] In reality, most people won't do it

I would rather instruct them how to use multi-person/multi-profile handling, than implement identity management in every extension...

But anyway, you could implement that as a second step.

What do you think?

[Maryse47]

Well, "security by obscurity" is the opposite of what this project advertises. Storing parts of masterpassword or hints like "my first pets name" undermines the security model.

Implementing identities as discussed by Wladimir in first post would be valuable.

[adrium]

The "security by obscurity" comment was not meant to be serious.

When only chaning the storage format, there is no list of used identities / master passwords. As I understood Wladimir, he is concerned about bad discoverability (obscurity) in this case.

I would not save password hints, either. It was just a possibility of what an identity list could contain. Of course, it can also just contain a username like that:

{ "hash": "1234", "name": "adrium" }

I implemented a proof-of-concept in https://github.com/adrium/pfp-standalone

[palant]

For reference, I am not currently working on PfP - I expect to continue work here around end of summer. This issue isn't my top priority however. I'd fix #86 and #79 first, plus some UI improvements, only then it's going to be this issue. You are free to have a go at it already and submit a pull request, just don't expect me to accept any features that are not discoverable.

[adrium]

Thanks for the heads up!

1. May I fork the code and adjust the implementation to my needs?
2. May I publish the extension in the Chrome store eventually? (Not sure, if I will really do that. What about the name? Would you be okay with something like Pain-free master password?)

Of course, I will be happy to help, if you ever wanted to pull some changes.

[Maryse47]

If you are going to publish it to Chrome store I would recommend using completely unrelated name to avoid confusion and to not looking like you try to mimic the original.

[palant]

You are free to fork the code, as long as you comply with the MPL 2.0 license terms. You are also free to publish your fork for others, but then it is up to you to maintain it of course. Please choose a name and icon that are different enough from the original that there cannot be any confusion. In particular, "Pain-free master password" is definitely not acceptable.

[adrium]

I just released Chrome and Web binaries :tada:

https://github.com/adrium/easypass/releases/tag/0.9.0

[palant]

I guess that as of PfP 3.0 the way to implement this is supporting multiple KeePass databases. Not sure whether I want to go there but reopening.

[palant]

Native host application now allows configuring multiple databases. If more than one database is configured, the extension will allow choosing one when unlocking passwords.