Part of #2456 - GUI bug for attacking specific accounts

[bitcrab]

at initial conecting, the GUI regard all the accounts with the same address as the accounts in the local wallet and get data accordingly, this provide chance for hacker to attack specific accounts to make it not able to connect, https://bitsharestalk.org/index.php?topic=27613.0 [4d]

[clockworkgr]

Interesting attack vector.

I'll think of ways to mitigate this.

Quick Fix:

Add a cloud-login key to your active authority, use that to login to the wallet, bypassing the multiple accounts loading. Is that right @sschiessl-bcp ?

@abitmore Can we add a check on -core create account/update account where you can only create an account with EXISTING public key X authority or EXISTING account authority if the operation is signed by that account/key ?

[clockworkgr]

if it's an attack however, the attacker will simply change the attack accounts to the new key so won't help much.

need a way to explicitly block get_key_references from being called or subscribed to

[abitmore]

IMHO better UI logic should be to not load all accounts at one time (aka do pagination or filtering) when detected that results is too big (too many accounts returned), while better core logic should be to not automatically subscribe to all accounts returned by get_key_references API when reached a threshold. Preventing certain accounts from setting certain keys is not the correct way to fix this.

[jademont]

Thousands of accounts were registered through cryptobridge in the form of
bitchabit-fucking-your-mothers2000
or
bitchjademont-fucking-your-mothers1000

at the same time their memo keys were changed to be same with my account, so when I open my light wallet, it's struck because thousands of accounts were being loaded.

[sschiessl-bcp]

Is the bitshares account that is being attacked "jademont" or another one? (can also PM me, is for testing)

[jademont]

Is the bitshares account that is being attacked "jademont" or another one? (can also PM me, is for testing)

account "jademont" is being attacked, and I am not sure whether there are more accounts affected.

[abitmore]

Update:
(I believe) due to a bug, the core didn't subscribe to the accounts returned, so effectively this is only an UI issue.

[startailcoon]

When wallet is loaded it loads, and subscribes, to all related accounts.

Without knowing if it would solve anything I started looking at some solutions. I think this is the main issue here, where we are talking loading linked accounts.

1. We're first populating all ref accounts to the loaded keys
   https://github.com/bitshares/bitshares-ui/blob/develop/app/stores/AccountStore.js#L307

2. Then we're loading ALL account refs, with subscription to true. Here we should not subscribe to get the account details of the ref account, which we just use to build the account list.
   https://github.com/bitshares/bitshares-ui/blob/develop/app/stores/AccountStore.js#L373

I've misplaced the changes I made, but it should only subscribe to the currently active account, and definetly not when we're running through the list of linked accounts.

[clockworkgr]

@startailcoon 's changes are in the right direction but as discussed in Ui group during the holidays the whole thing needs some major refactoring as although things are much better, UI still oversubscribes/floods nodes with API calls. Def need some better client side caching.

[startailcoon]

@clockworkgr indeed. Though, I see a major refactoring taking a lot of time and effort to complete.

Would this solve at least part of the problems that we have to begin with?

We should probably start an epic issue to work on the problem.

[sschiessl-bcp]

@jademont

What happens on your end when you load your account? Hangs? Error messages?

[clockworkgr]

Tracking this on #2456