Prevention of user's passwords being stored as plain text in bash history

Question

Say I want to find the password of a linux user sudoer account. Assume he uses a strong password. Assume I have physical access to the machine. I can get hold of his passwd and shadow file and brute-force it for days, or simply get a copy of his bash history file and use it as a word list.

I am not a hacker, but this method has worked a lot of times when I wanted to hijack someone's account. In my opinion, a lot of people accidentally type their password on the command line, especially if they don't touch type.

Lolz, I don't touch type either. Nor do the users of the systems I manage. How can I make sure that my super-strong password is not stored as plain text in my .bash_history?

I know I can keep deleting bash history, but is there any other means?

Answer 1

You can't, and you shouldn't try for the following reasons:

1. Imperfect technical ability (semantics)
2. Imperfect technical ability (centralized logging)
3. Alternate vectors (process table)
4. 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.

Answer 2

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

Answer 3

Edit the .bashrc file:

nano ~/.bashrc

Change the values of these two parameters to:

HISTSIZE=0
HISTFILESIZE=0

HISTSIZE is the number of lines or commands that are stored in memory in a history list while your bash session is ongoing.

HISTFILESIZE is the number of lines or commands that (a) are allowed in the history file at startup time of a session, and (b) are stored in the history file at the end of your bash session for use in future sessions.