First of all, all scripts/code should be written to use encrypted passwords when possible. However, this is often not practical due to time and other resource constraints. I assume you have these constraints and need a solution.

First of all, make sure that your web server executes as a distinct user and group. For example, the web server should run as 'web' and the group 'webgroup' with no others in that group.

You then change the ownership of the files/scripts to that of the web user (certainly not root, UID 0). You then set the permissions of the scripts to not be readable by other users, etc. and you do not give access to the directories by other users of the system.

It is best not to have users on the machine and to have shell accounts for casual users on another machine.

If this is not possible for some reason, then you should set the users up with a different root file system using the 'chroot' (change root) utilitity so the users will not have access to the filesystem, etc.

The best thing to do is to run the web server in production mode and not to have users on the platform (except trusted users). If users are needed to support the web application then do that in a development box without the scripts (or with bogus scripts/passwords to test) and then move the work to the production environment.

In the final analysis, the choice is based on operational risk-management. If you are doing credit card, personnel files, financial tranactions, etc. then the risk is great. If you are just running a small, not critical site, the risk is lower. The compensating controls are based on the degree of risk you are willing to take. No system can be made 100 percent 'unbreakable' and there will always be a way for a malicious user with good computer skills (and access to the platform) to read a shell script with unencrypted passwords.

In other words, there cannot be a good answer without knowing the nature of the application(s) on the server and the risk profile of the system(s).