For user passwords, we should always hash and salt them and then store the hash and salt in the DB. But what's the best practice for storing passwords that need to be eventually be in plain text? I don't feel comfortable storing a plain text password in SQL, but I have to send the password to a library so it can access something.
My thinking was that I could store an encrypted password on the database server and then decrypt on the web server. If both are compromised, I'm screwed. But if just one if compromised, the encryption gives me enough time to change the password.
What do you all think?
To be on a safer side, just hash the password and save, then you can compare user password input with the hash code in your database when you need to authenticate.
If you really need to get plain-text form of password ( which is really not good idea ) you can use symmetric encryption for security user passwords. But you must figure out how to keep private key in secure. I mean you need a private key in your code in order to decrypt data. Also all of your developers can access private key which means they can access plain-text too.
Also I suggest you to read this article. It's comparing hashing and encrypting user password. http://www.darkreading.com/safely-storing-user-passwords-hashing-vs-encrypting/a/d-id/1269374
Microsoft provide an API for this use case as part of the Crypto API. It's not particularly easy to work with, but provides much better security than storing keys in text files, or in the database.
It's fair to assume that if an attacker can get onto your database server, they have access to every system in your environment; and even if you think you have "time to change the password", how would you know your system has been compromised? Most attacks aren't noticed until much, much later...
