How Trustless and private is using Light Client with an API provider
User retainer asked
"How trustless (and private) is using BitShares 2 light + an Openledger API?"
I had some questions to which answers were difficult to find. I want to understand the trustlessness and privacy aspect of using BitShares through the combo of the BitShares 2 light client and Openledger.info as the API provider (or any other site that hosts such an API). I'd be thankful for any input on these matters.
You are always the only one in control of your private keys/accounts. OpenLedger and all service providers run just another full node on the network and APIs interacts directly with the blockchain. They also run a delayed full node that ensures user transactions never goes into a fork.
Same happens with web interfaces like OpenLedger, Maker dao, BitCash and every service running over the blockchain, into the DEx (decentralized exchange): web wallets just interacts with their own or any user specified full node.
.
1. Regarding the above use environment, which of these are known (even if just minimally, but to the extent of being able to identify users) to API provider site?Wallet name, account name, transactions, addresses, account password, private keys and brainkey.
Wallet name, private and brain keys stays client side. Account name, and transactions are public.
Graphene based blockchains uses account names instead of addresses.the set of accounts in your wallet however is a different thing as their balances and details are requested from the API server at the same time.
BitShares has a slight advantage over most satoshi/bitcoin based blockchains because it does NOT use addresses but only public keys.
2. Focusing on the brainkey: even if you answer that it never leaves the client, how much do you rely on this assumption? For example, if you used a custom mnemonic which is also used with a well-financed Bitcoin HD wallet (but your end-user security is very high, your only worry is the client communicating with the site API, and the mnemonic has a high entropy), would you feel safe?
Brain keys and private keys are only used to sign a transaction and unless you have loaded a hacked version of the html/js code (which shouldn't happen because of SSL) then you can safely assume that the keys don't leave the browser, or (even better) you can read the code and check for your self or pay someone to do so in an audit.
As usual in crypto currencies, the developers of the frontend cannot ensure the safety of the device using it. If your computer is compromised and you use BitShares, then your account will probably be compromised as well.
Regarding devices and connections, it's not bad to assume that your device or even SSL are already flawed. For signigicant sums sum it's always advisable to use only your most secure device and network or better even better use cold storage. xeroc has released a script to sign offline and a paper wallet.
3. Same thing as question 2, only for the account password. How well-guarded is this by the client from the API?
- The account password is only used to encrypt the private keys locally. As long as the wallet is locked, the keys are not in plain text. Encryption is AES256 IIRC
4. Is there any identifying information - apart from the IP address, (I'm just guessing here) the BTS addresses, transactions and the account name - which can be used by the API provider to identify the user? Like some cookie-like things, client fingerprint / user agent, wallet ID, anything?
- Afaik there is a simple self-hosted tracking widget in OpenLedger to get some numbers about the countries from which people are using it but I haven't looked into it much. Most important thing for frontend developers reading this is: There is no external Javascript being loaded in BitShares for security reasons!
xeroc:
As for brain key entropy: The entropy of brain keys is exactly 256 bit .. so the same as private keys.
Side remark: Considering Security, BitShares has a slight advantage over most satoshi/bitcoin based blockchains because it does NOT use addresses but only public keys.
Since addresses are only 150bits, there are multiple (2^(256-150)) public keys that theoretically derive to the same address and if you never spend from your bitcoin address, they all could do so.
Because BitShares does NOT use addresses but the full length public key, you could consider it slightly more secure.
rnglab:
There's still something to remark about hosted wallets. One of their benefits (plus all the ones they can choose to bring to users, and that's a lot), is being able to access your accounts from everywhere while still being the only one in control of keys.
But there's still a little trade off that's being worked on: private keys resides only on your browser's cache until you make a backup. Web wallet users should backup their keys just after creating an account in case they miss access to that computer, or if cache is cleaned, before a backup is done. Please correct mi if I'm missing something here.
Peermit is working on 2FA implementation for example. You can have 2FA providers who you only need to trust the funds (active keys) you want to, without compromising the ownership of your account (owner keys). A mail confirmation could be enough to approve a transaction from any device without messing with keys, wallet backups or seed brain keys. You could fund that account from the funds in your secure light wallet).
Also remember to lock your account when you leave a public machine, and if your want to ensure privacy over your accounts clean browser cache, as password only prevents operations (remember you are not logged in anywhere really, you just bring your encrypted keys to talk with the blockchain through the interface.
arhag
In the scenario we are discussing, I assume that to mean having the capability to do irreversible damage.
Assuming the user’s active key is safe, the 2FA provider can only deny access to but not really compromise their account. And if the user has set up the owner authority properly so that they have full control, that access denial is temporary. The user would have to fetch their cold storage brain key to sign a transaction using the owner authority to remove the 2FA provider from the active authority set and get back full control of their account with no funds lost.
If some attacker compromised the user’s active key (say by hacking the computer that they use the client on), then the user’s funds could be compromised as long as the 2FA provider was also colluding with the attacker, which is unlikely to happen. Even in this worst case scenario, assuming the user has set up an owner authority with proper cold storage keys, the user would still be able to recover access to their account (meaning they keep their account name) even if all funds were stolen.
I disagree with this statement in response to the question of how trustless is the BitShares2-light + Openledger backend combination. You do require less trust if you connect the light client to a full node that you operate. Granted, it is unlikely for a backend like Openledger to feed you bad data that causes you financial loss, but it is theoretically possible. For example, they can fake the market orders and make you place foolish orders on the DEX that you otherwise wouldn't have if you had the true information at the time. They could feed you transfer transactions that aren't actually in the real blockchain, making you think you received funds in exchange for some service or good exchange until it is too late to reverse (although perhaps this last one might require that they also trick you into believing the active witness set has changed?).
This statement is vague and could lead readers to believe something that is definitely not the case. If you use a 2FA provider like Peermit, you are not just giving them access to your funds (and everything active authority could do). It acts like a 2-of-2 multisig. To do anything with that protected account, you need authorization from both the user and Peermit. Keep in mind, Peermit could deny access to active authority authorization by refusing to sign anything (or being offline). But as long as the user still has owner authority control, they can take back control of their account by changing the active authority set.
Good points to state that running your own full node requires less trust , thanks for the clarification I'll remove that sentence.
Regarding the 2 of 2 multisig 2FA model, what else can be compromised besides day to day wallet funds?
What exactly do you mean by compromised? In the scenario we are discussing, I assume that to mean having the capability to do irreversible damage.
Assuming the user's active key is safe, the 2FA provider can only deny access to but not really compromise their account. And if the user has set up the owner authority properly so that they have full control, that access denial is temporary. The user would have to fetch their cold storage brain key to sign a transaction using the owner authority to remove the 2FA provider from the active authority set and get back full control of their account with no funds lost.
If some attacker compromised the user's active key (say by hacking the computer that they use the client on), then the user's funds could be compromised as long as the 2FA provider was also colluding with the attacker, which is unlikely to happen. Even in this worst case scenario, assuming the user has set up an owner authority with proper cold storage keys, the user would still be able to recover access to their account (meaning they keep their account name) even if all funds were stolen.
Thank you arhag, added to the FAQ.
As votes are removed when the post is edited, you can vote on BitShares FAQ static landing page if you want to support this idea. Thanks