Prevention of user's passwords being stored as plain text in bash history
You can't, and you shouldn't try for the following reasons:
- Imperfect technical ability (semantics)
- Imperfect technical ability (centralized logging)
- Alternate vectors (process table)
- Best practices (teach correctness)
Imperfect technical ability (semantics)
Let's assume you actually want to have a history file - it exists for a reason; helps you remember commands you typed, repeat commands by reference, etc. etc. In this case, you want to remove passwords that you've mistakenly entered. How do you do that?
You could have a plaintext list of passwords that you scan for within bash history files.... but then you have a list of plaintext passwords on your system.
You could look for commands like 'sudo' and 'su' and try to remove things after them... but the thing that's going to happen is someone will type 'sudp' by mistake, then type in their password to the prompt, and your filter won't notice it because of the very typo that led to the password exposure.
In short, the computer isn't smart enough to filter out inappropriate password entries; that's a semantic meaning problem.
Imperfect technical ability (centralized logging)
In bash 4.1, they introduced the ability to copy everyone's history logs to syslog. This was a legitimized version of functionality that people had been hacking, patching, and scripting into bash (and other shells) for years. If anybody else administers your machine - say, the IT group at work - then you may not have control over whether your command lines are being logged, quietly, without you ever knowing.
It's not just bash. The auditd daemon on Linux can be configured to log commands and arguments:
# grep oops /var/log/audit/auditd.log
type=EXECVE msg=audit(1443795447.953:2387443): argc=6 a0="sudo" a1="oops" a2="i" a3="typed" a4="my" a5="password"
#
That's a system-level setting, operating via the kernel, completely unrelated to whatever shell you use and regardless of any history settings you may have chosen for yourself.
Alternate vectors (process table)
Anything you type on the command line may show up in the process table, which is why tools that use passwords require them to be entered interactively. If you mess up (as in the sudo example above) and enter them as arguments, they're there for someone to grab out of the process list - and it's not that hard for someone to script a harvester that grabs command lines out of the process table.
Best practices (teach correctness)
Each of these objections has caveats... "If I don't want to keep using a history file", "If my sysadmin is hands-off", "If no one is watching the process table carefully".... But my definition of "best practices" is "stuff you do because you can't rely on other things going the way you'd like them to." So best practices is simply to assume that any password mistyped where it shouldn't have been is compromised, to change it immediately, and to move on with your life.
Any "solution" you could implement is partial and prone to failures outside the user's detection sphere. I'd rather not give people the false impression they're safer than they are.
I realize training people to do it is hard. Heck, training people to do anything is hard, and security is doubleplushard. But it's the right answer.
Well the method you described(cracking the hashes in the shadow file) cannot prevented as Linux doesn't or rather wasn't designed to prevent attackers with physical access to the machine.
If you want to delete the bash history(on logout) place the following in the files ~/.bashrc and ~/bash_logout:
cat /dev/null > ~/.bash_history && history -c && exit