Great question.
In bash, when you use "read" to get a password from standard input, the password is of course stored in plain text in memory. However, this is often the case for passwords in general -- something has to be storing them in plain text to use them. If it was encrypted, a way to decrypt it would have to also exist in memory -- thus the encryption wouldn't be very helpful then.
In this case I can offer two sets of best practices:
1) Use another method of authentication than password entered by the user. This could take the form of:
- For MS-SQL databases, using a "trusted" connection for authentication rather than a user-entered password. Other databases offer a variety of systems for logging in without a password.
- Join the computer to the domain and have the user login with Active Directory credentials. Then have the script use this authentication to login to sql. MS does publish sqlcmd and an ODBC driver for Linux that I've used successfully.
2) If you must use a password supplied by standard input, turn echo off in the bash script. Of course, bash scripts still need to be checked for possible exploits. If your script sources a file that is writable by any user, then of course that file could be altered to send the password to an attacker.
You may want to consider use of a passphrase file which is chmoded so only a single user can access it. Then simply read-in the password from this file. This is probably comparable in security to using the stdin password. While the user doesn't constantly type the password so some vulnerabilities (e.g. keylogger) would not exist; it would increase the ease of a password grabbing attack if someone just hacked the server.