Hiding User Password Entries from Admin

[GoogleCodeExporter]

Please describe desired steps of proposed new feature/enhancement:

Right now, when the admin logs in and does a search, he/she sees all of the 
password entries that have been created -- regardless of who created them.

It would be beneficial if the admin did see (or better yet, couldn't access) 
entries created by individual users.  This could be accomplished by changing 
the permissions scheme to remove admin or via a filter on the search capability.

What version of the product are you using? On what operating system?
WPS 1.2.1 on RHEL

Please provide any additional information below.

Original issue reported on code.google.com by holme...@yahoo.com on 31 Aug 2012 at 5:26

[GoogleCodeExporter]

It looks like WPS will be great for passwords for shared role accounts. The WPS 
admin is probably someone who should have access for those shared role accounts 
too.

But there are some systems that have individual accounts, but which aren't 
connected to our SSO/CSO system for whatever reason. It would be nice if 
employees could store passwords for those systems in WPS, without the WPS admin 
having access to them.

Original comment by d.b.mcg...@gmail.com on 7 Mar 2013 at 7:43

[GoogleCodeExporter]

I can add a configuration option to filter results out (its actually already 
there, but requires a code change).

BUT I don't want people to get a false sense of security.  The system 
administrator in most organizations would still have access to the database, 
and the encryption key/algorithm used by webpasswordsafe, so with enough manual 
effort they would have the ability to decrypt all passwords.  This product is 
meant to be a solution for shared passwords, not a "trust no one" encryption 
solution for personal passwords.  The later would require a significant 
redesign which I can look at for the future but in the mean time anyone worried 
about that should use a different solution (LastPass, KeepPass, PasswordSafe, 
OnePasssword, etc).  As an information security professional it is important to 
be completely transparent about the risks.

Original comment by joshdrum...@gmail.com on 17 Mar 2013 at 1:44

• Changed state: Accepted
• Added labels: Milestone-Release1.3

[GoogleCodeExporter]

What about an approach like that used by TeamPass, where personal (not shared) 
passwords are encrypted with a separate key/salt provided by the user?

Original comment by d.b.mcg...@gmail.com on 18 Mar 2013 at 4:50

[GoogleCodeExporter]

Yeah that was what I was thinking, basically a bolt-on feature that keeps the 
encryption of the two different types different yet integrates them both in a 
consistent user interface the best it can.  That wouldn't be a simple change 
compared to some of the other issues but I'll definitely look into it for a 
future major version.

Original comment by joshdrum...@gmail.com on 19 Mar 2013 at 3:59

[GoogleCodeExporter]

Note to self- can't really use the authentication credential as part of the 
personal key, since that would only work when using the default local 
authenticator.  If the password changed in another system via external 
authenticator (LDAP, SSO), or was using one time password / 2-factor authn it 
would break.  Need user to type in a different password/key at login for 
personal password unlocking?

Original comment by joshdrum...@gmail.com on 19 Mar 2013 at 4:13

[GoogleCodeExporter]

I'll leave this issue as holmesd3@yahoo.com originally submitted it, just 
filtering out results in the search menu.  Using a different "trust no one" 
encryption scheme per user for non-shared passwords I'll create a separate 
enhancement request issue for.

Original comment by joshdrum...@gmail.com on 20 Mar 2013 at 7:27

[GoogleCodeExporter]

Original comment by joshdrum...@gmail.com on 20 Mar 2013 at 7:27

• Changed state: Fixed