Lnd: Wallet password should be optional

[petertodd]

If the attacker has a copy of your wallet, in most sane threat models they probably also backdoor lnd to capture the password later anyway, rendering it pointless.

I set mine to 12345678, but really, an empty password should be accepted.

[Roasbeef]

If you don't want to use the wallet password, there's the --noencryptwallet setting. It was put in for usage within integration tests (and will likely soon be gated behind a build flag). It just uses a canned password in this setting.

As you note, it depends on your threat model though. If the attacker doesn't have the power to backdoor their running lnd instance, and they obtained a copy of the database from like a compromised Dropbox account or something, then the password is a level of defense.

[robtex]

if you use --noencryptwallet you will not get any cipher seed though?

[Roasbeef]

That's correct.

[petertodd]

@Roasbeef But why would I have the database on a Dropbox account? Lightning doesn't really do backups at this point. Equally, even in a normal wallet, I'd just use GPG for that encryption.

[chpio]

here's a workaround: https://github.com/Stadicus/RaspiBolt/blob/master/raspibolt_6A_auto-unlock.md

[yonderblue]

How to automate the current unlock with the rest api without relying on timing? The unlockwallet endpoint seems to return many things in success cases such as {"error":"context canceled","code":1} a 408 to {"error":"transport is closing","code":14} a 503. I have yet to see a 2xx. But usually any response besides connection refused or a 404 does unlock the wallet. The final resting case for that endpoint after unlocking seems to be 404, but the problem is you can get that before it issues the prompt to unlock too. So putting an infinite loop in that hits the endpoint until 404 isn't reliable. Using expect as in #1611 is probably better but I think all this illustrates that a simple no password option would be best.

[yonderblue]

just in case this helps anyone, this expect script and systemd unit file I believe are at least a reliable way to automate it even without an optional password. For example on a raspberry pi of mine:

/home/pi/lnd/lnd_expect.sh

#!/usr/bin/expect
set lndDist /home/pi/lnd
spawn $lndDist/lnd
set lndID $spawn_id
expect {
    -timeout 300
    "Waiting for wallet encryption password" {}
    default { send_user "default hit 1\n"; exit 1 } 
}
spawn $lndDist/lncli unlock
set cliID $spawn_id
expect {
    -i $cliID
    -timeout 30
    "Input wallet password" { send -i $cliID "password\n" }
    default { send_user "default hit 2\n"; exit 1 }
}
expect {
    -i $lndID
    -timeout -1
    eof send_user "got eof\n"
}

/etc/systemd/system/lnd.service

[Unit]
Description=Lightning Network Daemon
Wants=bitcoin.service
After=bitcoin.service

[Service]
Type=simple
ExecStart=/home/pi/lnd/lnd_expect.sh
Restart=on-failure
RestartSec=30
TimeoutSec=300
User=pi

[Install]
WantedBy=multi-user.target

[Kixunil]

Peter is right, anyone sensible running something like LND on a server would want this setup:

• Reasonably isolate LND from the rest of the things
• Make it so that LND restarts automatically if it crashes
• All backups are encrypted when transferred out
• Disk encrypted on system level if desired

Encryption enforced in LND is not only annoyance, but goes directly against "restart if it crashes" requirement. If an attacker can break isolation, he can read memory of LND, or kill LND and spawn a proces in its place pretending to be LND in order to sniff the password. (It can read TLS private key and the key must stay readable.)

Would you be willing to marge a PR providing an option to disable encryption based on these arguments? The unlock scripts complicate the system needlessly and increase attack surface.

[Kixunil]

If anyone is not convinced yet, I may have found the ultimate argument for this: admin macaroon is stored in the same directory. It's astronomically unlikely that the macaroon will be better protected than the wallet file.

Funnily enough, attacking admin macaroon might be even preferable to an attacker as he can trivially use it to send transactions, without any file copying or other complicated setups.