Advanced Crypt on Autounlock when staking seems useless

[TheCharlatan]

The autounlock feature allows users to stake, even if they have a locked wallet. Autounlock unlocks the wallet with the password the user has chosen and then encrypts it again with a special password. This password is just the Hardware ID of the machine the wallet is running on. This seems useless, since the password's goal is to protect wallets that an adversary already has access to. If this would be a hot staking wallet, the adversary would have access to the machine in any case, and guessing a hardware id is not hard.
Further, the macaddress is also used in this ID string, but only when QT_GUI is defined. This furthers obscurity and a difference in behaviour between daemon and gui wallet, that is not necessary.

[iFoggz]

I agree this is not the best thing. When I figured this out I just never did autounlock again.

[iFoggz]

also if someone did compromise the users machine they could technically just decrypt the wallet password right there and then take that with the wallet and run. i think itd be best to least mention caution on the use of this feature if it is to stay thou i'd support removal of it all together

[denravonska]

I vote for either removing it or adding a big warning both to the UI and to the password generation.

[iFoggz]

i agree to either. they must know the wallet passphrase can be decrypted easily if the said system was compromised.

[tomasbrod]

I Vote for removal.

[additude]

I didn't realize that auto unlock had been discussed for removal and ultimately removed until I installed the latest version on my headless Linux box a short time ago. So I am a late joiner of this discussion.
I agree with other posters about the relevance of adding a warning notice for users who wish to use the feature but not removing it.
It's one thing to protect the user from security faults, but it's quite yet another to protect the user from themselves. I don't feel that protecting me from myself is anyone else's responsibility except that of my own. When I am notified of the risk, then I can make a responsible decision.
There are many, many things less secure than the Auto Unlock feature and besides there are other built in layers of security on top of the Wallet. In general, a users machine would practically have to be "targeted" specifically for their GRC Wallet to expose any Auto Unlock for Staking Only Security Threat.
I realize there is risk, there is risk in everything, but it's also my choice of convenience that I make at my own risk and I am quite capable of managing my own risks just fine without others intervention.
Please reinstate Auto Unlock and provide an adequate detailed warning for the output of the "encrypt" function.

[jamescowens]

We are not reinstating the functionality in its current form. It provides essentially NO additional protection as compared to leaving the wallet unlocked or unencrypted. Please see #546 to understand why. And to comment on leaving protection up to you... we already provide the option of running the wallet unencrypted. At least the user knows exactly what risks they are taking when they are doing that. In the case of auto-unlock, especially in the headless situation, the warning you mention would not be heeded, or in many cases even seen. It is a bad idea to provide false security to users, even with a warning attached.

…

Sent from my iPhone

On Apr 12, 2019, at 4:49 AM, additude ***@***.***> wrote: I didn't realize that auto unlock had been discussed for removal and ultimately removed until I installed the latest version on my headless Linux box a short time ago. So I am a late joiner of this discussion. I agree with other posters about the relevance of adding a warning notice for users who wish to use the feature but not removing it. It's one thing to protect the user from security faults, but it's quite yet another to protect the user from themselves. I don't feel that protecting me from myself is anyone else's responsibility except that of my own. When I am notified of the risk, then I can make a responsible decision. There are many, many things less secure than the Auto Unlock feature and besides there are other built in layers of security on top of the Wallet. In general, a users machine would practically have to be "targeted" specifically for their GRC Wallet to expose any Auto Unlock for Staking Only Security Threat. I realize there is risk, there is risk in everything, but it's also my choice of convenience that I make at my own risk and I am quite capable of managing my own risks just fine without others intervention. Please reinstate Auto Unlock and provide an adequate detailed warning for the output of the "encrypt" function. — You are receiving this because you modified the open/close state. Reply to this email directly, view it on GitHub, or mute the thread.

[denravonska]

I would rather see us using the OS keyring for storing this type of data than rolling our own, easily breakable variant. If it's possible, that is. For now you can achieve auto unlock using RPC and scripts. I know it's not as easy as the previous version but it's close to as insecure and, in the end, does the same job.

[additude]

The user has the option to not even encrypt their wallet. Encrypting the wallet is not even mandatory and the "SECURITY" threat of just that single issue alone outweighs any security threat posed by the Auto Unlock 100 fold. A user can have an un-encrypted wallet..... but can't use Auto Unlock if they wish....
That just plain doesn't make any sense to me.

[additude]

"At least the user knows exactly what risks they are taking when they are doing that. In the case of auto-unlock, especially in the headless situation, the warning you mention would not be heeded, or in many cases even seen."
At least in the case of comparing it to an unencrypted wallet it's some security. Not every hacker, per se, that can even get into a machine would know specifically how to and what to do to reverse Auto Unlock...
They would have to have specific prior knowledge of the software function and that means more like their mission would have to be direct target and they would have to get past all the other security and maybe even chown....
Your saying that you want to take away the remote access to a car because a traditional metal key in hand is safer....then if that's not good enough, just leave your car unlocked everywhere you leave it...
I say that's non-sense.

[jamescowens]

Look. I am not going to get into an argument with you on this. Anyone that has the resources to break into somebody's computer and mount an attack against the wallet itself will also have the resources to derive the hardware ID of the machine. Read the original write-up above carefully. What auto-unlock does is re-encrypt the wallet with the hardware ID as the passcode. This provides no additional protection over storing the passcode in a text file to be fed into an RPC command for unlock from the point of view of the attacker. It is one rather trivial additional step.

The core dev team is discussing alternative implementations of the auto-unlock feature on Slack. We would welcome a PR if you have ideas on how to implement a secure alternative.