Anyone who uses a screen locker surely can recall a situation where they approached their computer and started typing their password to unlock it even though it was never locked. Even if the machine is configured to lock automatically after a period of inactivity, there may be situations when power saving blanks the monitor even before the automatic locking happens.

If one’s lucky, they realise their mistake in time before hitting Return in a chat window. It’s not uncommon however that one ends with the password blasted into ether over IRC or Google Docs; lazy people might ignore the secret getting saved in their shell history file but even that should facilitate, often annoying, password change.

What if I told you there’s a way to avoid those problems? A one simple trick which will eliminated at least some forms of possible leaks. Simply prefix all your passwords with /! (slash followed by an exclamation mark).

Slash

Lines starting with a slash are treated as commands by many — though not all — chat applications. This originated in IRC so virtually all IRC clients will do this, but the same feature was adopted by many other programs such as Element or Slack. When trying to send a password beginning with a slash onto a channel or private conversation, the application will refuse to do anything reporting an unknown command. For example:

04:55 -!- Irssi: Unknown command: foobarbaz

[(status)] /foobarbaz

Of course even then the protection won’t work if there’s already some text in client’s input field; perhaps because one started writing something to send to the channel but got interrupted.

Exclamation mark

Exclamation mark meanwhile has a special meaning in popular interactive shells (by which I mean bash since I’m too lazy to actually test any other shells). When present the shell will attempt a history expansion (based on an arcane grammar that I reckon no one actually remembers). If no expansion is found, rather than executing the command (and thus sending it into possibly world-readable history file) the shell will complain. You can test it easily by trying to execute echo !foobarbaz in your shell:

$ echo test
test
$ echo !foobarbaz
bash: !foobarbaz: event not found
$ echo !foobarbaz^C   # ‘echo !foobarbaz’ is populated by shell
$ history | tail -n2
    6  echo test
    7  history | tail -n2

This doesn’t always work. For example, if a non-letter follows the exclamation mark the expansion will likely succeed. The histverify shell option can help catch those errors. (I’m again talking bash here but I assume other shells worth their weight in salt have similar option). When it’s active, executing commands including a bang requires a confirmation after the history expansion happens. In other words, pressing Return key once won’t execute them. For example:

$ shopt -s histverify
$ echo test
test
$ echo !$foobarbaz
$ echo testfoobarbaz^C   # ‘echo testfoobarbaz’ is populated by shell
$ history | tail -n2
    8  echo test
    9  history | tail -n2

Conclusion

There are still places where the /! trick won’t work. I’ve already mentioned chat applications which don’t recognise slash as a command prefix, but there are also tools for collaborative editing such as Google Docs which broadcast entered text as soon as a letter is pressed on the keyboard. (The former issue may be solved by using bitlbee for all instant messaging needs).

Prefixing the password by /! isn’t a panacea but it may prevent at least some instances of accidental credentials exposure. Since there’s virtually no cost in adopting this policy, why not do it?