4 ms·
KeePassX file in a repo with long password is a reasonably good solution. Not perfect, but open source and you can segregate by user/team. Also in a team there
by freefaler 2y ago
KeePassX file in a repo with long password is a reasonably good solution. Not perfect, but open source and you can segregate by user/team. Also in a team there can be 1 person who has write/update duties and updates the passwords if there a shared ones (not the best approach).
BTW, not related to the passwords is to put everything non-public serving behind a firewall and access it only via individual VPN keys.
- marcosdumay 2y agoDon't put in a place where history is saved (as in, don't put it in a repo, put on a shared disk). Also, make sure to rotate the key when people change.
- codethief 2y ago> Don't put in a place where history is saved What risks & attack vectors do you have in mind here? Also, in how far is this an issue with KeePass (whose files are encrypted)?
- marcosdumay 2y ago> What risks & attack vectors do you have in mind here? People with deleted passwords not being able to access the old file, or really any kind of mistake being irreversible.
- codethief 2y agoI'm afraid I'm still not following. Isn't the point of having a history precisely to be able to roll back in case of mistakes?
- marcosdumay 2y agoYou don't want a rigid history on the case of some mistake exposing the data. (Like a weak password.) Backups that you can erase work fine, but version control will create trouble.
- codethief 2y agoYeah, rotating the passwords when there is a possibility of a leak would be mandatory of course. (As it should be anyway.)