How is this secure?

Maybe I’m dumb, but I don’t understand how this can be part of the wallet rpc.
image
If I am running a Chia wallet, literally anyone can just grab my private keys?

I just tested this in my app and it 100% returns everything anyone would need to steal all of my Chia without even a notification in the wallet.

Maybe this only works with software running on my own system? But still, even if any software that runs on my computer could do this, that is still insanely insecure isn’t it?

Overall, I don’t understand the security of the RPC at all, it just seems that you can do absolutely anything with it with no checks.

Okay, so after some experimenting, I get how SSL makes it so I can’t just connect to anyones rpc. It is still seems pretty scary to have the RPC be so powerful.

I think having some kind of login, or having to accept in the wallet when some of the riskier rpc commands are executed would be a good thing.

Someone could easily create some bootleg versions of games or software using chias software that could skim peoples private keys without anyone knowing. That would be a horrible hit to Chia’s reputation for security.

1 Like

As discussed on Twitter - this is secured by the unique TLS certificates and is needed to allow the GUI to access key items.

There are additional security controls we can add to some of these but there is a direct useability tradeoff on certain of them. The more important issue is that if software has free reign in a user’s account, it’s too late.

My goal is to provide a way to sell video games using Chia. Video games are software that runs on the players system. I can’t in good conscious continue my project in this way with the assumption that players will install the official chia wallet on their systems. I will have to find a way where chia is more sandboxed so that games couldn’t easily access it.

I think adding those additional security controls is extremely important for less security savvy users. I know Chias priority is targeting very serious users, but it would be a bad look for Chia to have a bunch of kids who got interested in Chia getting their XCH stolen because they installed some sketchy game.

I’m confused. If someone installs malware, they’re done - regardless of where it came from.

If a user installs malware and they’ve got all sorts of extra passphrases on their private key - what keeps the malware from keystroke logging the private key response and then quietly unlocking the private key?

Is there some vector for malware that I’m missing? Do you really assume the games you enable will be malware?

1 Like

Well, you can make it a lot harder on attackers, so why wouldn’t you? They wouldn’t have to install a key logger, or anything like that that has a chance to get caught by an anti-virus. They would just have to do a few calls to the RPC and that’s it, nobody would ever know. Games are almost all closed source and they auto update all of the time. It doesn’t even have to come from my software, any game or app developer out there could sneak that into their code to get the keys of anyone who happens to run chia.

I don’t assume it, but you have to be prepared that it will happen.

It would not install a key logger, it would be a key logger triggered on a call to the private key.

What people keep saying to you is that, if malware has full access to the userspace it will win.

This is true even in the say Ledger example. Targeted malware will intercept the signing request for the hardware and insert the bad actor’s destination address that was derived to look like the intended destination instead. The user will have to be super vigilant to notice that the hardware key isn’t singing the correct transaction.

If someone else can arbitrarily run code in your userspace you’re basically fully compromised.

I’m not talking about complicated attacks here, I’m not a security expert. A literal moron could do this to steal from people using Chias software. They might not catch you, but they will catch someone.

Your threat analysis assumes malware. Once you assume malware, you’re done.

If Google Chrome decided to sniff for all our private keys and upload them to Larry and Sergey, it would and it would win - regardless of anything you did in your local userspace.

You have to be able to sign things. Once someone else has “you” permissions, they can sign things…

I don’t even know what to say man, I don’t like having a single point of failure. Being able to put a password doesn’t seem unreasonable to me. It would do a lot to prevent simple attacks for most people.

If you’ve installed software that has the same access to your userspace as you - it can grab your password too.

There are three levels of access control on modern computers. Administrator, User, and Sandboxed in the web browser. Anything that has permissions above the web browser can copy your password and use it whenever it feels like.

1 Like

There are three levels of access control on modern computers. Administrator, User, and Sandboxed in the web browser. Anything that has permissions above the web browser can copy your password and use it whenever it feels like.

I wonder if we could use the native OS access control mechanisms to add some layer of security. What this essentially implies is running the Chia wallet server and GUI under the Administrator/Super user, and restricting the software which can make the risky RPC calls to ones at the same privilege level.

I can’t in good conscious continue my project in this way with the assumption that players will install the official chia wallet on their systems. I will have to find a way where chia is more sandboxed so that games couldn’t easily access it.

I wouldn’t assume the current security situation to be in any way permanent. As we know, the Chia team is actively working to improve custody and security from the smart coin layer with rate limited wallets and clawback payments, to hardware layer by working with hardware wallet vendors.

I can already imagine intermediate solutions for such a marketplace where users would be asked to fund a dedicated wallet, from which any outgoing payment to any address other than a single pre-approved withdrawal address has to be signed-off by your platform. Game developers would have to register payments with the distribution platform (example: 1. buying the game, 2. buying a weapon skin, 3. buying a season pack), and the platform could scan for unexpected outgoing payments and eventually activate clawback functionality to retrieve funds from the developer accounts if there are suspicious transactions (example: an user suddenly empty their wallet to buy millions of coins in a newly published game). This is just off the top of my mind, the space for security breach mitigation is huge thanks to programmable coins.