[Worker Proposal] OpenLedger User Security Worker Proposal

[clockwork]

As a witness I would like to suggest add a "Witness Key" to update signing key and publish price feed only.

Please see : https://github.com/bitshares/bitshares-core/issues/1061

Stefan's concept there is a generic solution to exactly that problem.

[Bangzi]

As a witness I would like to suggest add a "Witness Key" to update signing key and publish price feed only.

Thanks for your input, Bangzi. Could you please elaborate more, what is the purpose and the logic behind it?

Now witnesses use Private Key to update signing key and publish price feed. The Private Key stored in server and if the server compromised, hackers able to transfer the fund.

[yury]

As a witness I would like to suggest add a "Witness Key" to update signing key and publish price feed only.

Thanks for your input, Bangzi. Could you please elaborate more, what is the purpose and the logic behind it?

[Bangzi]

As a witness I would like to suggest add a "Witness Key" to update signing key and publish price feed only.

[yury]

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.
 

[abit]

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

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.

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.

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.

[yury]

Thanks a lot for your feedback, Fabian!

I, too, support efforts to bring more security to the blockchain.
The costs for 50k$ for specifications and research is somewhat difficult to understand given that
many community contributors already have a list of features that overlap 80% with your desires.

At this time I am only aware of proposal from Stefan about custom active permissions, and still it needs more technical investigation. Could you please advise, what other features you have on your mind?

I would like to kindly request that the Openledger development team gets in contact with the
bitshares-core development to discuss which specs already exist or are near completion, rather
than duplicate efforts.

Sure, this is what we are going to do.

Further, I have made contact with the developer of Scatter already and he would love to help
integrate BitShares into Scatter after his refactoring. So, I would rather get things started with
the existing foundations of scatter than re-invent the wheel.

It may be the good option, but there are some concerns as well.
I had a closer look at Scatter and here is this app is compared to our proposal IMO:
- Scatter is one wallet per device for many keys for many blockchains, while our app shall be able to handle many wallets for one blockchain, each protected with a separate password.
- Scatter is not able to show accounts and keys relationships (e.g. multisigs, accounts hierarchy, etc).
- Scatter can't generate new Bitshares keys for you.
- Scatter does not have auto sign functionality.
- Scatter does not have blockchain listener and notifications mechanizm
And finally, Scatter is an independent app. Today it is opensource, but we have no idea if it will be opensource in a year. We also have to rely on the app owner and align to his app roadmap. Being integrated into Scatter is nice, but we believe we shall also have a separate Bitshares dedicated open source app. 

Last but not least, I would like to iterate over the existance of a Proof-Of-Concept implementation
for Steem/Graphene for the original Trezor. Specs are more or less complete and we could go into
implementations any time there is funding and human resources that support development.

Nice option, but same concerns as for Scatter.

Finally, I much enjoyed reading this proposal. OpenLedger established itself long ago as a solid pillar
in the BitShares ecosystem. Glad to see your desire to give back to the community.

Thanks a lot, Fabian! Your opinion is extremely important and your contribution to Bitshares can't be overestimated.

[yury]

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

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.

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.

[xeroc]

I, too, support efforts to bring more security to the blockchain.
The costs for 50k$ for specifications and research is somewhat difficult to understand given that
many community contributors already have a list of features that overlap 80% with your desires.

I would like to kindly request that the Openledger development team gets in contact with the
bitshares-core development to discuss which specs already exist or are near completion, rather
than duplicate efforts.

Further, I have made contact with the developer of Scatter already and he would love to help
integrate BitShares into Scatter after his refactoring. So, I would rather get things started with
the existing foundations of scatter than re-invent the wheel.

Last but not least, I would like to iterate over the existance of a Proof-Of-Concept implementation
for Steem/Graphene for the original Trezor. Specs are more or less complete and we could go into
implementations any time there is funding and human resources that support development.

Finally, I much enjoyed reading this proposal. OpenLedger established itself long ago as a solid pillar
in the BitShares ecosystem. Glad to see your desire to give back to the community.

[Digital Lucifer]

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.

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

[yury]

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

[yury]

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!

[sschiessl]

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.

[yury]

Dear Stefan!

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

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.

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?

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. 

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.

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

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

[sschiessl]

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.

[fav]

I'd actually vote for a worker to integrate and maintain scatter functionality, that would add some awesome synergies in my opinion.

other than that I agree with sschiessl, key changes etc should be handled by core worker. perhaps your devs could liaise with @fox and you get paid from that worker

[sschiessl]

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

[ccedk_pro]

Executive summary

After a recent phishing attack, the OpenLedger team has gone through a series of massive brainstorm sessions, aiming to come up with a solution, which makes further attacks impossible, much harder  or at least, that minimizes the impact of a potential attack. It has became obvious that these types of attacks will continue as more and more new businesses join the BitShares ecosystem and new faucets are launched. User security becomes a paramount focus for the community. Below is a list of the changes we would like to introduce to allow BitShares users to protect themselves and mitigate the risk and impact of phishing attacks or any other attacks that can cause private key loss.

Briefly, we propose the following changes:

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

Given the complexity, importance and potential impact of security for BitShares and for the community, it is difficult to have a complete solution for the features mentioned above without thorough brainstorming, research, analysis and design.

This worker is for funding the Analysis and Architecture phase to elaborate on the features mentioned above, and to describe and estimate specific and feasible security solutions that can be implemented later.

Total duration: 2 months, Aug 6 2018 - Oct 5, 2018.

Total cost: 49 080 bitUSD.

The Solution

Here is how we envisage the changes mentioned above at the high functional level.

Active vs Owner private keys: Separation of Duties

At this time, each account in BitShares is separated into:

• Owner Permission: This permission has administrative powers over the whole account and should be considered for ‘backup’ strategies.
• Active Permission: Allows to access funds and some account settings, but cannot change the owner or Active permission and is thus considered the ‘online’ permissions.

This is a great approach, but if both Owner and Active private keys are stored in the same pocket the user loses both keys if a successful phishing attack was done or the wallet was compromised.

We do believe that Owner and Active private keys must be stored in different wallets, preferably on different devices.

A User uses only the Active key for day-to-day operations, but when they need to manage their account, the Owner key should be used.

Hence, to minimize the impact of a successful phishing attack on a User’s regular account (if a user suspects that Active key is compromised), we suggest to limit the Active key permissions in the following way:

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

Each of these settings can be modified only with the Owner private key.

These changes will provide BitShares users with a set of powerful tools, allowing them to configure security settings of the account so that users' assets stay safe even after a successful hacker attack or a security breach.

Device-Tagged Transactions

Security and privacy are key requirements of any BitShares user. However, they often contradict each other. Being anonymous is good, but anonymity is something that gives bad guys more power. If your key has been stolen, the blockchain will accept transactions signed with this key. It does not matter if they were sent by you or by the hacker. You can configure your account so that two or more signatures are required for each transaction, but if you are an active trader and submit hundreds of transactions daily, this is not a realistic option. To help active traders to keep their funds safe we suggest implementing a new transaction type - device-tagged transaction.

Let's imagine that a user has a trading BitShares account with two Active keys. If a user submits a signed device-tagged transaction, then a witness node adds DeviceID to the transaction and records it in the blockchain. DeviceID is a hash of particular data that belongs to a particular device (e.g. hash of IP address, MAC or any other device-specific information). The key requirement here is that the DeviceID is unique for each device, but the device cannot be uncovered by this ID to protect privacy of the user. Now that the user has sent their device-tagged transaction to the blockchain, they can confirm this transaction on another device.  Moreover, once a user recognizes transaction or device, they can enable auto-sign, so that future transactions from this device are automatically signed and fulfilled.

This gives the user the ability to filter out any transactions coming from an unauthorized device, even if one of the Active private keys has been stolen. It’s a method that  allows a two-factor  authorization approach even if hundreds or thousands transactions are submitted by the account daily.

User-Friendly Accounts and Keys Management

As a typical non-technical BitShares user, you need a web, mobile or desktop application to interact with the blockchain. And the problem is that you have to trust the application provider. Besides, the current new user registration and account management approach is extremely non-user-friendly. This leads to users leaving BitShares for other exchanges.

We  suggest that a new open source application should be implemented, allowing users to:

• View and manage their wallets, accounts and private key in a very transparent and user-friendly manner: e.g. view wallets stored on this device, accounts and private keys in the wallets, their relationships and interdependence (e.g. accounts hierarchy or multi-signature accounts), generate and replace private keys, and set limits for Active keys.
• Sign or auto-sign transactions, with the ability to see and filter Device ID, if a device-tagged transaction has been generated.
• Notify users by listening to the blockchain, searching for specific transaction types (e.g. transactions signed by specific key) and sending out emails and displaying notifications.

The applications can be created as a browser plugin, desktop and mobile app, and users can use a particular application type depending on their needs and habits.

To register and trade, users will still need to use a proprietary or BitShares standard application, but they now will have the ability to use a trusted open source locally executed application to configure their account security and manage keys.

Even if a user registered and traded on a phishing site, they can still protect their funds  by replacing private keys or configuring multi-signature account in a separate trusted application. We hope that dealing with private keys in a stand-alone open-source application only will become a standard way for most users.

The Worker Proposal

Worker Scope

OpenLedger believes in a transparent and steady, step-by step development approach. Before we jump into major implementation project, we would like to perform detailed technical investigation, which will deliver clear and straightforward specifications and estimation of the new features and components to be implemented.  This worker is to fund this Analysis and Architecture phase only. As soon as the investigation for a particular feature is completed and specifications along with estimations are delivered to the community, new implementation workers will be submitted for public approval.

Work Approach and Costs

Immediately upon the approval of the worker, OpenLedger will allocate the resources listed below to perform the investigation and provide the deliverables. Reports outlining time spent and current progress to be published on bi-weekly basis. At this point, we estimate the Analysis and Research to take 2 months. Below is the resources and costs breakdown.

Worker daily pay: 3 885 BTS

Payment

We strongly believe in a bright future for BitShares, and this worker will make a great contribution to that. Therefore, we would like to be paid in BTS, BitShares core asset. Accepting BTS instead of bitUSD also allows us to not over-utilize daily workers budget by claiming more BTS than is needed to cover the current costs, leaving room for more workers to be executed simultaneously. In order to avoid over- and under-payment, we will settle the payment at the end of the worker using the current price of BTS in bitUSD. If, due to BTS rate fluctuations, more funds will be needed to complete the job, an additional worker will be created. If we need less effort or BTS rate increases, unspent BTS will be sent back to the reserve pool.

All payments will be vested for 1 month.

Openness for suggestions

Security is a complex but vital topic for BitShares and for blockchain technology. There has to be a way between tightening up security and staying anonymous, while keeping everything decentralized. 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.