Geth’s insecure unlock
The Ethereum ecosystem is rapidly changing. Being open source software, a lot of improvements can pour in every year. A side effect of this is that “tutorial” and “quickstart” blogs can possibly get outdated, and leave readers confused. I was one such reader. In this article I’m going to describe an interesting error I ran into while trying to unlock an account with geth and the subsequent learning that ensued.
As per the tutorial I was following, I first started an Ethereum node using
geth --ropsten --syncmode "light" --rpc --rpcaddr 127.0.0.1 . My intent was to start a “light” node on the Ropsten testnet and deploy a contract to it using Truffle. I then ran
geth attach \\.\pipe\geth.ipc to connect to the Geth console via the IPC end point and tried to unlock an account which I would use to deploy the contract. Here Geth errored out with this message.
At first this did not make complete sense because I was connected to the Ethereum node via IPC, not HTTP. So what is Geth complaining about?
I took a step back and had a closer look at the geth command that I used for starting the node.
geth --help (sounds like a pun :D) easily revealed explanations for each of the options I had used.
--rpc Enable the HTTP-RPC server (deprecated, use --http)
--ropsten Ropsten network: pre-configured proof-of-work test network
--rpcaddr value HTTP-RPC server listening interface (deprecated, use --http.addr) (default: "localhost")
As the help page says, the
--rpc option enables the Ethereum node’s HTTP-RPC server. What is this HTTP-RPC server and what is it used for?
Back to our error — Why is account unlock forbidden when the HTTP server is enabled?
If an Ethereum account is unlocked and the HTTP interface is exposed to the outside world (i.e. on the host’s public network interface) then it is possible for anyone to transfer funds from your account or sign a transaction using your account’s key. In 2018 there were reports of a massive campaign by attackers that scanned for internet-exposed Ethereum wallets and mining equipment. Also common, was to have accounts mysteriously emptied by bots soon after they were unlocked.
To mitigate this potential vulnerability a change was introduced in Geth to disallow unlocking accounts when the HTTP or websockets interface is enabled. This comment in the pull request describes how Geth can be expected to behave at present. However it’s still possible to unlock accounts whilst exposing the HTTP or Websockets interfaces by explicitly providing the
--allow-insecure-unlock option to geth. This must be used with great caution.
Its worth noting that by default the geth node doesn’t start the HTTP and WebSocket servers. And even when they are explicitly started using the
--ws flags, not all functionality is provided over these interfaces for security reasons. These defaults can be overridden with the
--wsapi arguments, or with
Best practices when using accounts
geth --ropsten --syncmode "light".The node prints the IPC endoint address in the logs on startup. You can then attach to the IPC endpoint using
geth attach path/to/ipc/geth.ipc
- When using the CLI, it is recommended to do the account unlock interactively as opposed to specifying the password directly as part of the command. For e.g. The following command starts a node on the Ropsten testnet with the specified account unlocked. The HTTP-RPC and Websockets interfaces are not enabled.
geth --ropsten --syncmode "light" --unlock 7a67c39db201fbba9e9e0e...
$HOME/.ethereum/historyfile. If you execute
personal.unlockAccount(eth.accounts, "myethsecret", 5)you will be able to see your password printed in the .history file mentioned above. By default the directory in which your .history file is located is only readable by your own system user. But if your system user account is compromised, your password will be visible in your history file.
- Consider using a wallet to interact with the Ethereum blockchain. For e.g. using Metamask you can securely manage your account, use your account to authenticate to websites and send transactions.
In this post we tried to undertand why Geth disallows unlocking accounts when the HTTP or Websockets interface is enabled, potential risks in that scenario and best practices when working with accounts.
Thats all for now. Stay tuned for more! Please share your thoughts in the comments below and 👏for this post if you found it helpful.