Channel OFFLINE if LND Wallet Locked about raspibolt

[Stadicus]

AFAIK this is exactly how it's supposed to work. For now, I set up an email alert that sends a message every time the service is started (not yet in the guide, a bit complicated with Gmail certs & stuff).

I am not sure yet, if this can be automated in a safe way.

[Stadicus]

Quick extract from the LND Slack discussion board (highly recommended):

Stadicus: Does anybody have best practices on how to handle the manual unlocking of the LND wallet? From an operations (not security) perspective, it's not ideal to manually enter it every time the node itself or the service (maybe due to a crash) is restarted.

X1: @Stadicus how often is service being restarted in practice? Any automation of password entry kind of negates the security doesn’t it? Curious on the operational flow that would be improved from not manually entering the password? it’s done via RPC so you can unlock it remotely from an rpc client if that helps

X2: @Stadicus if you want to have auto-unlock, you can create your wallet and restart every time with --noencryptwallet. it's still encrypted, technically, but with a default passphrase. but yeah, in a setup where you're looking for reliability and security, you central monitoring/management stuff can unlock via RPC with a password stored in a secure store (i know ansible has this capability for example)

[robclark56]

Thanks for the answers. So this prompted me to find the 'default' PW code in LND ... which is below.

// We wait until the user provides a password over RPC. In case lnd is
// started with the --noencryptwallet flag, we use the default password
// "xxxx" for wallet encryption.
privateWalletPw := []byte("xxxxx")
publicWalletPw := []byte("xxxxx")

[Note: I replaced the actual PWs with xxxxx for this post .... which is a bit paranoid I will admit as the LND code is public anyway. But my point is that I now know what the default PWs are ... and anybody that can use Google can learn them too].

What this says is that all std LND implementations use the same default PWs if --noencryptwallet is used (e.g. to unlock the wallet automatically at bootup). Seems like a security hole big enough to drive a bus through, like routers left at factory default with login/pw = admin/admin.

Hmmm. How to proceed?

1. I don't want to use --noencryptwallet as the world now knows my wallet PW
2. But want to have my LN node run 'lights off', including after a power failure.

Guess this is why this is called BETA testing

:-)

Appreciate this discussion belongs elsewhere ... but adding this post for completeness.

[Stadicus]

Thanks for sharing this additional data. In my understanding, there is no way to securely store the "secret" for unlocking the wallet on the same machine. If the system is breached, the attacker would gain access to both and could easily run off with the funds.

Therefore, either unlock manually, or let a second system with a secure key storage unlock the node with RPC remotely. This makes sense in my opinion, but I'm not sure myself how I want to proceed.