For that you need to open a ticket at OpenLedger helpdesk. I'm afraid we can't help.

You can also try Telegram channel @OpenLedger4Members

201808-bitshares-ui - No because I feel we need an actual UI/UX design team to work on this project. I personally feel this WP is more of a bug killing WP so the purpose is misleading.

I'd be eager to discuss your vision and critic for the UI proposal, in the hopes if swaying you. This is your journal so that can be done on another medium as well if you will.

I don't have a fixed role in the worker proposal, but I am actively developing for it.

Thank you very much for your response! Here are my thoughts

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.

Agreed. This can be handled by the UI when signing up, e.g. give the user a checkbox "Enhance account security" which is on per default and would require an active password and an owner password (for both cloud or local wallet login). I bet the BitShares UI team would be happy to welcome you.

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?

I am a firm believer of a flexible approach, while not altering existing behavior. Ease of use can simply be achieved by providing an additional, easy to be found button: "Create trading key" and "Restrict markets" that do the right backend calls. I would not restrict the capabilities of the backend because it allows so many more use cases. The BSIP is in draft stage, I would be happy to collaborate.

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?

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.

Totally agreed, it should be optional, but it would be awesome as integration. Signing locally outside of the BitShares UI makes ANY phishing attempt immediately worthless as there is no access to the private key at any point. It would require some rework of the UI to allow to define your active account without giving the private keys. The approach to be preferred IMO is to not even let the phishing party get the key in the first place. Anyways, key management outside in an external open source app would be really great!

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.

This is merely a question of a button that does the right operations on the backend. An active key that got compromised, or might be compromised, should never be enabled again, ever. I'm unsure what other use case it has. If the key was lost it's also lost after re-activation.

We would like to open discussion and we particularly welcome suggestions and ideas about new security features and the best way to design a specific feature

I appreciate that you are collecting feedback like mentioned in your initial post. I just noticed that the worker proposal has already been created, leaving no margin for alteration in terms of its approach. I personally would have loved explicit collaboration of the UI and core worker to include OpenLedger into the community development. Disclaimer: I don't carry any significant voting or proxy weight. I am part of the BitShares UI team and managing the infrastructure worker that is done by Blockchain Projects BV.

Dear OpenLedger Team,

thank you for the initiative! I read it and would like to comment on it. To your summary:

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.

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.

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?

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?

To Active vs Owner key:

- 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.

- 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.

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

Best regards,
 Stefan

Could the commitee shed some light on the background discussion of that decision?

Quote from: kimchi-king on July 19, 2018, 07:36:52 am

Quote from: abit on July 17, 2018, 09:42:01 pm

Sounds like a good idea.

Thanks Abit for sharing your thoughts on this WP. I hope that other proxies & committee members follow your lead to come forward and express their support or concerns publicly about this initiative.

That is something that should have been requested and started PRIOR to launching the worker proposal on-chain so you could tweak it before putting it up for voting. (and no, a few hours, at least as far as the forum post is concerned does not constitute "PRIOR")

Prior evaluation happened, but mostly in their telegram. I voiced mine there, if anyone cares I happily repeat them.