Q1. What is the problem that you are trying to solve?
Found DB and SMTP Password is Saved in Cleartext in passbolt.php, which is obviously not a good find for a password vault, making me question Passbolt’s security all around.
Even though its only readable by root a password vault is a high priority target for privilege escalation attacks.
Please find a way to Salt and Hash these…
Versions:
3.1.0-1 (/var/lib/apt/lists/download.passbolt.com_ce_ubuntu_dists_focal_stable_binary-amd64_Packages)
Hi @onyxwolf,
Welcome to the forum, please read the code of conduct Passbolt | Code of conduct . Spreading fear uncertainty and doubt is not allowed on this forum. I renamed the subject because of this.
This topic has been discussed in the past. Passbolt is regularly reviewed by professional 3rd party security researchers, solving this has never been one of their recommendations.
The gist of it this is that it is normal for a web application to store credentials to connect to third party service such as database or email. Your suggestion of “salt and hash” it not applicable, which makes me think you’re confusing it with the best practice for storing user credentials.
Anyway, if were we encrypt these credentials (say with the private key), these will need to be decrypted by the application at runtime anyway to connect to the services. And if an attacker has access to the runtime, then they can do as they please anyway. Encrypting the credentials would not slow them down, it will only slow the application.
If you are not comfortable storing credentials on file, you can also use environment variables, and inject/rotate them at runtime using a 3rd party system (like vault from hashicorp). Ultimately it would only marginally improve your security posture.
In other words the developers are doing things in a least effort way; thus my original statement of loosing confidence. My prevailing point in this reply is that security in most forms is not an absolute barrier but to slow down and frustrate an attacker until they give up.
“Your suggestion of “salt and hash” it not applicable, which makes me think you’re confusing it with the best practice for storing user credentials”: Yes, you are storing credentials to an email account that could possibly be used to do more damage to that user / or company than just local creds, so handling with at least that level of best practice seems reasonable. For a DB connection, hashing works certainly, and salting is just to make sure that using the same hash for PWs aren’t as easy to guess. At minimal you could stick the SMTP password in the DB.
"if were we encrypt these credentials (say with the private key), these will need to be decrypted by the application at runtime anyway to connect to the services. And if an attacker has access to the runtime, then they can do as they please anyway. " Perhaps, but which is more difficult privilege escalation to filesystem access and a search of said files for the keyword “password”, or parsing through runtime traces to detect passwords being used? (And, tho I’m not an experienced hacker, I don’t think privilege escalation to filesystem means necessarily runtime access).
In the unlikely case I am just speaking with ignorance, my final point would be that at minimal APPEARING to have better consideration for password security would be advisable to instill confidence, seeing as you are developing a password vault.
Thank you, for your effort and speed in replying to my concerns.