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.

[realspencerdupre]

Came here to voice my agreement. Here's a scenario:

The folks at myNode do a nice job with an automated unlocker script. To make it easy, they automatically generate the password and save it in another folder. What security does this provide if we save our passwords in the clear for our unlocker scripts?

They fail to mention that the password is different from the main myNode login password.

User (me) attempts to transfer the .lnd folder, moving the node to a new machine. Forgets/doesn't know the wallet.db password is elsewhere.

User wipes SSD, because 1TB SSDs aren't cheap and I don't exactly have a bunch of extra ones lying around.

Now have no password, OhNo.gif, must resort to recoverchanbackup and SCB.

This is a foot gun. --noencryptwallet should be a first class flag.

[Kixunil]

@realspencerdupre great point, sometimes too much "security" can cause loss. Forgetting being more probable than theft is considered common knowledge by all Bitcoin security experts I know. Why shouldn't it apply here?

[guggero]

I don't necessarily disagree with the point that the wallet password should be optional.
But I do want to clarify a few things:

• The --noencryptwallet (or --noseedbackup as it's called now) flag has two effects:
  1. It uses a default password for the encryption of the wallet.db and macaroons.db files. All other databases are unencrypted.
  2. It initializes a wallet automatically on first startup and the seed for the wallet is never shown to the user and cannot be extracted later. The only thing that's stored in the wallet.db is the HD master root key (xprv). You can use that to manually recover funds but you currently cannot restore your node from it (seed to xprv is irreversible because there's hashing involved). walletunlocker: Allow wallet to be created from extended master root key (xprv) #4717 will change that.
• If you have the seed, you don't have to care too much about the encrypted content of the wallet.db as that can be recovered by the seed and a chain rescan (some metadata like TX labels and transaction info from Loop/Pool might get lost but no funds). In the situation where a wallet password is lost a node can still be migrated without loss of funds or channels by re-creating the wallet from the seed, stopping the node and replacing the channel.db file from the old node (only if the old node was stopped and didn't run for a single second after the copy of the channel.db file was created!!!).

To make a long story short: Yes, we might want to allow not needing to set a password. But first we need to refactor quite some code to disentangle the two effects of --noseedbackup.

[Kixunil]

@guggero AFAIK everyone in this thread is aware of current working of --noseedbackup - otherwise we would mistakenly use it. :) Indeed, it needs to be refactored to work differently, that's what we (at least I) proposed.

I am very happy that you're willing to accept such change. Maybe I will be able to find some time to help with it but I'm currently very busy.

[Kixunil]

I'd like to move this forward, so here's a proposal to resolve it:

The main goal is to get rid of the unreliability of automatic unlocking via unlocker scripts. The unlocking mechanism must allow consumers to get a seed or set their own It'd also be great to make migration from existing unlocker scripts easy. The mechanism must not introduce unreliability or block consumers from writing their scripts reliably. That means if the consumer wants to make the operation safe even in presence of power failure at any instruction, the API must make this possible.

• lnd will accept wallet_password configuration option and will use it to unlock the wallet if present. It may be empty.
• If wallet_password is present and the wallet is not initialized, lnd will fail to launch the daemon
• A new option--init-wallet is available on lnd binary, that means not lncli. If this option is present lnd will initialize the wallet. --seed-file option is required in that case. The daemon will not be launched after successful initilization. lnd just exits with 0. If initialization fails for any reason, lnd exits with non-zero exit code.
• --seed-file option specifies path where the seed is stored. It can be a pipe or a regular file. lnd will only read this file, not modify it in any way.
• --init-wallet requires wallet_password to be configured this password will be used for encryption
• If --init-wallet is used and the wallet is initialized, then a private key is generated from the seed and compared to the internal private key. If they match, lnd just exits with 0 (making this no-op), if they are different, lnd prints a readable error message and exits with non-zero exit code.
• --gen-seed option on lnd will cause it to just output the seed as JSON object and exit with 0. --entropy-source-file may be provided - LND will read exactly 32 bytes of entropy from that file and turn it into seed. Entropy source may be a regular file, pipe or character device.
• --gen-seed and --init-wallet can not be specified at the same time

If this is accepted I will codify these requirements as tests written in bash. I will also provide an example of safe, reliable init/unlock script with comments explaining all relevant details.

Rationale

• Allowing password to be specified in config file makes migration easier and less error-prone.
• Multi-stage initialization with ability to set the seed allows implementing reliable recovery or advanced schemes.
• Separating initialization from launching of the daemon makes error reporting easier.
• Putting --init-wallet and --gen-seed into lnd binary avoids the requirement to have lncli installed.
• Allowing "double initialization" with the same seed enables making the unlock script idempotent. This is critical to ensure reliability and safety.

[realspencerdupre]

This makes sense

lnd will accept wallet_password configuration option and will use it to unlock the wallet if present. It may be empty.

But for the rest, I don't see the need for initializing/generating a wallet automatically. Sounds scary.

[guggero]

Sounds good! I'm assuming this binary operates on the data directly - it doesn't use RPC, am I correct?

Correct, it would create the wallet DB file directly (nothing else, lnd does the rest automatically, like the macaroon DB and macaroon files themselves) with the seed and password (and entropy if provided).
If this is enough to satisfy your last point, then that tool could either exit with a success status if the wallet already exists, or exit with a special error code. That way you could always invoke the command on startup.

Interestingly I heard claims that env vars are not safe for storing secrets

Maybe that's something more common in Docker/Kubernetes environments where you don't want hard coded secrets in files (because that's harder to setup/maintain in a "stateless" environment) or command line flags (because they could be visible even to non-privileged cluster users), so secrets injected in environment variables are quite common.
But I envision all three options (flag, file, env) to be supported, just like we did in LiT: https://github.com/lightninglabs/lightning-terminal/blob/master/config.go#L123

I'm not sure what problem does it solve, can you clarify?

Just to turn lnd into the "try to unlock or fail, never spin up unlocker RPC" mode. But maybe that's not needed since the presence of any of the password flags/options would already achieve that.

Cool, I feel like we have a possible way here that could cover all use cases of this thread while remaining fully backward compatible. And to be honest, this would also make our cluster setup way easier. We definitely also started feeling the pain of this.

[Kixunil]

But I envision all three options (flag, file, env) to be supported

I'm not sure about argument, it's quite a big footgun. I contributed to electrs in the past to disable similar option reasoning that failure is better than vulnerability and it did actually save someones ass. Maybe allowing it being empty would be an interesting compromise but the clutter of command line may still be a good reason to prefer other means.

I will leave the decision to you just please document the footgun if you decide to allow argument.

But maybe that's not needed since the presence of any of the password flags/options would already achieve that.

Yeah, I think the presence of password option should do it automatically.

Cool, I feel like we have a possible way here that could cover all use cases of this thread while remaining fully backward compatible.

I agree, I will try to write a test script so the implementors can use it to check the implementation.

[guggero]

@Kixunil: I created a PoC in #5150. Everything file based should work, the k8s stuff is mostly for our own cluster setup and is not yet implemented. Please let me know what you think and whether this would work for your use case.

[Kixunil]

Whoa, great speed! I started writing the example script and test script but didn't finish. I guess I will publish the draft and then improve it.

[dannydeezy]

Personally I would love it if there was a single flag added to lnd called --wallet_password or --wallet_password_file, which handles both unlocking and initializing. It could initializes a new wallet (if none exists), or unlock the existing wallet if it does exist. This would allow me to have 1 simple helm chart for my Lnd deployment that works for the first and later deployments, and no manual work required to initialize the wallet.

While I hear this argument @guggero :

I'd strongly advise against adding yet another wallet related set of flags to lnd itself.

Perhaps just this single flag (rather than a set of interdependent flags) might be ok?

I don't like the idea of having different behavior required to init or unlock the wallet, and I think it might be nice to compress these into a single flag. In the past I wrote a script that did this and it worked nicely for my Lnd deployment. Perhaps I'm missing something though :)

[guggero]

That sounds very dangerous. Wouldn't that mean that you never even see your seed? If your wallet.db file is deleted or gets corrupted, you're definitely screwed. Even with only having the wallet.db, there currently isn't a supported or documented way to recover/rescue your node in case of a failure.
Or how would you expect the seed to be handled during initialization, @dannydeezy?
Also, I really really hope that script isn't used in production!

[dannydeezy]

Good point about the seed, I think that's what I was missing - thanks!

Just also took a look at your PR #5150 and left a question there.

Re: the script, if It remember, I think I manually backed up the mnemonic after writing it to the disk... not great haha

[ddiekroeger]

@Kixunil: I created a PoC in #5150. Everything file based should work, the k8s stuff is mostly for our own cluster setup and > is not yet implemented. Please let me know what you think and whether this would work for your use case.

This is great!

[guggero]

think I manually backed up the mnemonic after writing it to the disk

Please do me a favor and check whether that is the case asap! If you don't have the seed there's still a way to extract the xprv when you have access to your wallet.db file, so that you at least have something!

[dannydeezy]

@guggero the node that used that script was swept and inactivated almost two years ago :)

[Roasbeef]

Thinking of closing this as we have the wallet file option, and also lndinit that will fully automated the creation and storage of the password itself.

[petertodd]

Thinking of closing this as we have the wallet file option, and also `lndinit` that will fully automated the creation and storage of the password itself.

I do not agree. There are lots of security postures where the password is totally pointless. Personally I set mine to abcdefgh on every lnd wallet I have. I'm far more likely to lose funds from it being inconvenient to auto-restart lnd on reboot - followed by exploitation by a peer - than I am having my backups be compromised.

[Kixunil]

@petertodd there is wallet-pasword-unlock-file now so the problems associated with mandatory password are solved except for minor annoyance.

[petertodd]

...and using that ends up in pretty the same situation as a passwordless wallet file. But more convoluted and with a risk that the password will be lost. Not to mention, calling this a "password" is misleading anyway. Since the threat model is offline decryption, we actually need something with significantly more entropy than what would normally be considered a password to resist cracking efforts. On August 20, 2022 10:02:43 AM GMT+03:00, "Martin Habovštiak" ***@***.***> wrote: ***@***.*** there is [wallet-pasword-unlock-file](https://github.com/lightningnetwork/lnd/blob/a58553d1bd239f0ba8bf2fe267112b964ee6bc3c/sample-lnd.conf#L259-L264) now so the problems associated with mandatory password are solved except for minor annoyance.

…

-- Reply to this email directly or view it on GitHub: #899 (comment) You are receiving this because you were mentioned. Message ID: ***@***.***>

[saubyk]

Converting this to a discussion. Can be reverted to the issue or a new one opened up if any development is planned for this.