Using Passwords in Scripts in bash

You need to hardcode a password in a script.

This is obviously a bad idea and should be avoided whenever possible. Unfortunately, sometimes it isn’t possible to avoid it.
The first way to try to avoid doing this is to see if you can use sudo with the NOPASSWD option to avoid having to hardcode a password anywhere.

This obviously has its own risks, but is worth checking out.
Another alternative may be to use SSH with public keys and ideally restricted commands.

If there is no other way around it, about the best you can do is put the user ID and password in a separate file that is readable only by the user who needs it, then source that file when necessary .

Leave that file out of revision control, of course.

It may even be possible to use that SSH method to access other data on the same host, but it’s probably much more efficient to use sudo for that.

But what about accessing data in a remote database, perhaps using some SQL command?

There is not much you can do in that case.
Yes, you say, but what about crypt or the other password hashes?

The problem is that the secure methods for storing passwords all involve using what’s known as a one-way hash.

The password checks in, but it can’t check out.

In other words, given the hash, there is theoretically no way to get the plain-text password back out.

And that plain-text password is the point—we need it to access our database or whatever.
So secure storage is out.
That leaves insecure storage, but the problem here is that it may actually be worse than plain text because it might give you a false sense of security.

If it really makes you feel better, and you promise not to get a false sense of security, go ahead and use ROT13 or something to obfuscate the password.

ROT13 only handles ASCII letters, so you could also use ROT47 to handle some punctuation as well.