Dear Xeroc, could you please clarify you point here? What is the reason for you to not unvote those witnesses who feed updated prices to bitUSD?
1. You believe applying BSIP42 is safe for bitUSD.
2. You have concerns regarding BSIP42 applied to bitUSD, but you don't want or afraid to make a decision and take actions.
3. Any other?

Thank you very much in advance!

Does the above analysis make sense to you?  We can concentrate our collective efforts on supply side solutions if so.

I would mostly agree with the analysis. To go further regarding the supply side, IMO people are not motivated enough to create (borrow) MPAs because the risk being margin called is quite high in volatile/bear market as of now.
How about adding one more incentive to those who takes the risk? As mentioned above, MPA is a good service/product, it has big demand. And therefore it can generate revenue stream (e.g. market fees). IMO it would be nice if those who take the risk and support (borrow) MPA shall have a cut from the revenue. To avoid passive yield harvesting, the borrower shall release borrowed MPA to the open market:
1. An MPA owner specifies market fee portion he would like to share with borrowers.
2. A user borrows the MPA providing the collateral (this may be BTS or any other MPA or UIA, as specified in the MPA collateral settings).
3. To receive the cut of the MPA market fees, the user has to place market sell order on MPA:Collateral asset (e.g. bitUSD:BTS) market.
4. As the MPA is being bought and sold by other users, market fee goes to the MPA's owner vesting balance, particular part of it (as specified in 1st step) is proportionally sharedropped to all borrowers who has executed step 3.

Some implementation concerns/details:

1. the user account is a multi-sig account, e.g. 2/4, one key in a hot wallet, one key in cold storage, one key controlled by a trusted 3rd party, one key on a special device;
2. every time when creating a transaction with the hot wallet, it adds a special ID hash into it, for example, set it into a custom operation. In this process, a proposal can be used;
3. The ID hash should be different for every transaction (a one-time key). For example, the user have a secret phrase only known by himself or probably shares with the trusted 3rd party, can be "mysecret123", when crafting the transaction (with the hot wallet), the wallet generates a random number, hash the phase plus the random number, put the random number and the hash in a custom operation;
4. the 3rd party or the special device knows the phase, so can check whether the transaction is proposed by the real user, then add one more signature automatically or not.

Actually this approach doesn't need to change anything in core, but all can be done in UI. The hard thing is how to make it noob friendly.

Thank you very much for your input, Abit!
The original idea was not to sign every transaction, because this won't work for traders. Once a device is "authorized", all further transactions coming from it are auto signed. The exact "device tagging" mechanizm may vary and your approach may also be implemented. Still, we believe it is not client app to tag the transaction, because it may be compromised. It shall be done on a node IMO. Anyhow, this is what investigation phase is for - assess different options and select the best one.
 

Thanks a lot Milos for your feedback!
Please see my comments below.

Quote from: yury on July 24, 2018, 09:28:18 am

Dear Stefan, it seems we are very close in terms of the security approach and specific features implementation. We launched the worker as it is, but also would like to get in touch with BBF to find the best ways to deliver. If needed, we will create another worker to implement the approach that works best for all parties.

I would be supporting any contribution to a Core Team Worker with funds designed for integrations/developments as these are, and I would be giving my vote to the new worker when all steps mentioned are done and confirmed by all parties.

Awesome! We will do our best to be integrated into Core Team Worker.

Quote from: yury on July 24, 2018, 08:08:26 am

The idea is to make a node to generate the device id and store it along with the transaction, so a client has nothing to do with that. 
Ok, so that would basically be some kind of hashing of user given values (e.g. MAC adress or IP, some kind of hardware hash etc.). Sending that information to the node (server) brings aspects of user identification and anonymity in play. Question in my head: Is there a way to tighten security without compromising identity?

I would not be supportive towards centralized server that will host all of that private information from a user/client when we don't even have basic KYC form. It's creating another security risk plus illegally compromising privacy information of individual without previous signed agreement to it. E.g. "Terms of Use" thick box with defined legal obligations and limits of the service, clearly stating which information is being obtained, how is being stored and what would happen if it gets compromised. Everything would be in a need to be legally defined, and each user has agreed to it during registration of his account, which still brings us back how we would process all accounts already created without it and as mentioned how it would affect all that anonymity hype with account creation we currently present ?

Thanks in advance for feedback and will be following up on communication progress and new worker.

Cheers

It seems to me that in the worker text we were not specific enough and this causes some misunderstanding. Let me try to provide more detailed workflow, I do hope this will make the idea more clear.
1. A User has an account with 2 Active keys.
2. He submits a "device tagged" transaction to a node, signed with 1st Active key.
3. The node takes user's device ID (e.g. hashed IP) and stores along with transaction. There is no way to guess IP knowing the hash, so we don't store any private information.
4. On another device (e.g. mobile) the user sees that a transaction with specific ID has been submitted. He know he has submitted this transaction on another device, so the ID attached to the transaction must be "safe". Now he can auto approve all transactions having this ID.

With this approach we do not store any private info and do not violate user's anonymity, we just allow him to identify which transactions were created by him from another device, by tagging them with unique device ID.

Another thing I'd like to add to my comment as a question:

Many things will need to be handled by the core. This worker is for analyzing and architectural planning. That means the proposal will end with a really detailed BSIP for those cases that will then be voted on, correct? Afterwards, if approved, it would be picked up by the core team so a consecutive proposal for that might not be needed.

 I agree with fav, focusing the proposal on the external Scatter like tool and integrating your devs for the parts that touch the core into the core worker might be beneficial, as it would also open up a line of collaboration of OpenLedger and the core team.

Dear Stefan and Fav! Thanks a lot for your opinion on that, collaboration with the core and UI teams may be a good option. I will reach Ryan to find the best way to move forward. Will keep everyone posted! Thanks again!

Dear Stefan!

We do appreciate your feedback! Please find the replies below.

Quote

To minimize risk of both keys being stolen at the same time: Separate Active and Owner private keys, encourage their storage in different wallets (preferably on different devices).

This is a great idea. Already now in the BitShares UI  one could create two local wallets with two different passwords defined on account creation.

Correct, sophisticated users can configure their private keys and wallets in many ways at the moment, but a regular user typically follows standard flow which is not that safe. The main idea behind our proposal is to make accounts, keys and wallets management easy and user friendly.

Quote

To minimize the impact of Active private key theft: Severely limit permissions for Active private key, while allowing to more fine-grained permissions control with Owner private key.

There is work done currently to formulate a BSIP for this: https://github.com/bitshares/bitshares-core/issues/1061#issuecomment-398017083 , which introduces custom active permissions, which would allow to create a "Trading private key". In combination with you proposed account and markets whitelist it's a great defense. The active key behavior should not be altered imo.

Agree, your proposal is very close to our vision. At the first glance your approach seems to be more flexible, while our proposal is more straightforward and easy for user comprehension: it implements user+admin approach. I believe a particular balance to be identified here to make this feature powerful yet easy to use. BTW, what is the status of the BSIP?

Quote

To minimize the risk of transactions coming from unknown sources signed with your private key: Introduce new Device-Tagged transaction allowing users to identify and block transactions sent from an unauthorized device and implement multi-signature accounts, essentially moving to 2FA.

This sounds interesting. How do you ensure that an attacker does not mimick the device id that is stored on-chain?

The idea is to make a node to generate the device id and store it along with the transaction, so a client has nothing to do with that. 

Quote

To make keys and account management more secure and user-friendly: Create simple desktop and mobile applications that allow users to easily manage their accounts and private keys, create multi-signature accounts, sign transactions, enable auto-sign feature, and receive notifications for specific transactions.

This would be gread, similar to Scatter I suppose? Is the idea the following: You are running said new program on the local computer and other application like the BitShares UI can request to get transactions signed?

Yes, similar to Scatter. Not sure for now if web apps like OL or Bitshares UI shall be required to use the app to sign the transactions, it may be an optional feature for good guys. We discussed several options and decided that you can't make all faucets/gates to use the app, anyhow there will be new phishing apps coming and we shall be protected against them. So the main idea is to deliver opensource trusted app to users to allow them to change their private keys, auto-sign correct "device tagged" transactions and manage Active permissions, so that a hacker has little chance to steal your funds even if he has your Active key.

Quote

- Daily transfer limits can be set for each asset. So that a hacker who steals the Active key is not able to drain the account immediately.
 - Limit the markets where Active key can place orders. So that a hacker can't sell the assets he got illegal access to for their fake assets (Markets whitelist)
 - Specify accounts the user can transfer to. So that a hacker is not able to move funds to their own account (Accounts whitelist).

I like those three. Transfer/Trade volume limit, markets and transfer whitelists. In combination with my above mentioned trade authority only a market (and possibly volume) whitelist would necessary. In the same way the current asset blacklisting functionality could be optimized. For example: The well known binancecleos account could be blacklisted for OPEN.EOS, which *should* have the effect that no one can transfer OPEN.EOS to that account.

Agree!

Quote

- Owner is able to suspend the account activity. This means that if a user suspects that Active key is compromised, they can suspend the account Active key and then any transaction signed with the compromised Active key will be blocked.

This is already possible simply by removing said active key.

Correct, but it is not very easy for a regular user to add/remove keys, also, if you lost the key, you may be in big trouble. Enable/disable the key is much more user friendly and safe.

In general: Will everything be available as open source and/or implemented directly in the BitShares UI?

Yes, sure. Generally, we believe that user security is something essential for further development of Bitshares ecosystem. Another successful attack can kill the trust, and unfortunately no faucet can be considered 100% safe. The users must be protected on core level.  Although there are particular protection tools available at the time (e.g. dynamic accounts permissions), and some more improvements were proposed proposed, there should be a consistent solution designed and delivered, this is the goal of this WP.