Open meshuamam opened 1 year ago
Hello @meshuamam, thanks for contributing to the Password Pusher community! We will respond as soon as possible.
Nice idea on implementation @meshuamam.
Up to now the policy has been:
The FAQ covers point number 3 to an extent:
Running an private instance of Password Pusher for your company or organization gives you the peace of mind that you know exactly what code is running. You can configure and run it as you like.
On the other hand, if your instance gets hacked and the encryption broken, malicious entities now have a targeted dictionary of passwords to brute force accounts in your organization. Note that this would be limited to pushes which haven't yet hit their expiration limits.
In this respect, the public instance at pwpush.com is may be superior that it contains only passwords without identifying information mixed among users from around the globe.
With that said, more security is never bad and this is a good proposal.
I'll give it some thought but I'm a bit under water currently with my day job and other tasks. I'll post back here when I have some updates. Thanks for pointing this out!
Really a nice feature request +1
🚀 Feature Request
Today, if someone has access to the db + master key, they are able to read all unexpired secrets.
Instead, we can create a mechanism where the only way to read a password is with the generated url. This way, even if a malicious individual is able to access the db + master key, they wouldn't be able to read secrets.
In order to implement this, we need to do 2 things:
This way, without having the url itself, the password can't be decrypted.
🔈 Motivation
Reduce the impact of someone getting access to a production machine, which includes both db access and the master key.