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.