To determine definitively the degree to which this might or might not be "a prudent step", I think you would have to do some original security research on the possible replacements, which include:
- Debian's dash
- OpenBSD's ksh
- Busybox ash
- MirBSD/MirOS mksh
- ...and certainly others
Mark's answer suggests that at least OpenBSD's has received security scrutiny already, but I'm not sure of the extent or whether there's evidence to back this up (clearly, they did not apply any scrutiny to a cornerstone of comms security (OpenSSL) until recently when they forked it into LibreSSL). On the other hand, it's pretty clear to me that nobody had bothered to read the Bash source for security until recently, or "shellshock" would have been discovered a long time ago; the whole "function importing" thing is a huge red flag that any security researcher would scrutinize as soon as they saw it (and hopefully recommend the entire feature for removal). But for the others, it's not as clear.
What is clear, though, is that all of the above have a much smaller attack surface than Bash. In order for an attacker to take control over a program, there has to be some input channel. These can of course be non-obvious things like resource limits, system clock, etc. but they're still inputs; a program with absolutely no inputs is trivially non-vulnerable. The security design bug in Bash is that it's taking potentially untrusted inputs (the contents of arbitrary environment variables) and subjecting them to complicated processing (parsing as code). On the other hand, as far as I'm aware, none of the above-listed shells do any processing of the contents of environment variables (except individual ones with specified established meaning like
PS1, etc.) or other input; they just treat the contents as abstract data which is passed through.
So from a security design standpoint, even without auditing these alternatives, I would estimate them to be safer choices than Bash. Whether that will remain the case it not clear. Certainly Bash is getting a lot of new attention right now, which other shells are less likely to receive, so we could end up with most of the issues in Bash getting fixed while issues in other shells remain unknown. Then you have various factors to consider, like whether you're likely to targeted individually, in which case using less-mainstream software may be a liability.
Personally, I use Busybox ash most places. If nothing else, both ash and dash use about 1/5 the memory of bash and start 2-8 times faster, so they're very practical choices from a non-security standpoint as well.
#!/bin/bash- I am not aware of a way to prevent this short of removing bash from the system entirely.