Password auditing (Part II)

As an Admin, I want to be able to see all the passwords in the system (not have acces to the passwords, but know they are there) and see the owner of the password, and how long ago they have been changed, and the password strength. So If I see a password hasn’t been changed for a long time, or it is very weak, I can ask the owner to change it. Maybe this could even be automated?

Also if a user is deleted (happens mostly because they leave the company), I want the owner to be reminded to change the password the user had access to.

Hi @pimzwager,

Could you please move this request to the backlog section: https://community.passbolt.com/c/backlog ?
From my perspective, I see 2 / maybe 3 features:
1- As an admin I should be able to list all the passwords available in the system, without their secrets, in order to see who they are shared with or some other metadata.
2- As a password owner, I should receive an automated notification when a password has to be rotated. (this will probably become part of a wider scope regarding password rotation policies).
3- As an admin I should be able to audit which passwords are too weak (this will logically become part of audit log at some point).

For 1, maybe @cedric or @remy have some views about it?

For 3, we’ve been having this in mind for quite a while. However, it is not clear yet how we’ll accomplish this without storing sensitive information in the database. Since we can’t calculate the strength of a password for a user that doesn’t have access to it, we’d have to store it somewhere. If we store it, we potentially disclose a sensitive information. I am curious to see if the community have opinions about it though.

thank you, moved to backlog

On 3, could you calculate the strength while the password is entered. and save this date as an attribute of the password?

The problem would be that, if we store it, then it will be possible for an attacker that gains an access to the db to identify the weak passwords and attack them first. I agree that if someone has an access to the db, there are probably other things to worry about. But still, storing this in the DB would increase the attack surface.

However, there are other ways to do this, but more complex. Like encrypting the password strength, as well as some other sensitive metadata for the users that need it only. This could include the users without access to the password but with admin privileges.

You wouldn’t store the password length, you would store a complexity rating, which includes more than password length. Dashlane does this, admins can’t see which passwords are weak, just how many a user has and the average password rating. The user can see individual password rating.

I was talking about the password “strength” (= complexity rating), not “length” :wink:
Even this would disclose information about the password that could potentially allow an attacker to narrow down his surface of attack (like targeting which ones to try to brute force first). But I would agree that the scope of the attack would be rather limited, and it would involve that the attacker has already an access to the database, which means that there would be many other things to worry about at that point.
Anyway, storing the complexity rating in the db is still an option that we are considering. I just wanted to point out what the implications are so that it opens the debate.