Dear community,
this is my 10,000th post in this forum and I have prepared something special to show my passion about BitShares (and the
Graphene Technology) and try to establish a profitable business in this ecosystem:
Two Factor AuthenticationI would like to introduce a second factor authentication service for the BitShares network. It will require users to
request a new account by sending a memo and a registration fee to on of our accounts. To secure your new account, We
will make heavy use of "proposed transactions".
Note that we are currently running in a beta testing phase and hence recommend to only use small amounts of
your money to test this system. It is also required to use a patched cli_wallet for now. I hope to see proposed
transactions in the GUI wallet somewhen in Q1/2016. Until then I can only recommend very advanced users to try out this
service.Costs for the usersProviding increased security for your funds is a service that cannot be offered "for free". Hence, we need to cover our
costs and find a way to fund future development. During the beta testing we will offer our service at a cost of
0.4% of the transfer amount and
200 BTS account registration fees (see below).
Only during the beta testing, the service fee will be
0.0%. Accounts will be migrated from the beta testing once
we eliminated all issues yet to be found.
Procedure (for discussion)
Registration- A customer sends a 200 BTS from his account to the account peermit-reg and puts his email address in the memo
- These funds will be used to register your new "secured account" (of which YOU will be the only owner)
- We will send you an email containing the secured accounts' name
Funding your secured accountYour secured account can be funded similar to any other account: Just use the account name you have received by email.
You should take a look at the permissions tab to see that YOU are the sole owner of the account and are among the list
of active permissions with half the weight that is required by the threshold.
Spending funds- To spend funds from the secured account one of these conditions have to be
met:- your OWNER key signs the transaction
- your ACTIVE key AND our ACTIVE key sign the transaction
By this, it is ensured that- you control the account and can opt-out of the service
- your active key alone cannot spend funds of that account unless you also have access to the mail account
- You propose a transaction that spends from the secured account
- You approve your own proposal
- We notice that proposal and send an email verification token to your registered mail address
- Upon clicking the verification link on the mail, we will sign the proposal
- After the expiration time your proposal will validate and the proposed transaction will execute.
Security aspects- The customer can Opt-Out at any time since they own the "owner" authority
- Transactions need TWO signatures (ours and yours) or your owner authority
- Owner key of our multisignature account is stored offline and never touched an internet-connected device
- Active Key of our multisignature account can (and will be) rotated on a regular basis to ensure that a compromised key cannot sign future proposals.
- Access to the signing machine is restricted by VPN and API-control restrictions
- If the proposal is not verified, the funds will not move (of course)
- This scheme allows to "combine" several multisig schemes with additional required authorities by 3rd parties
- Aribtrary expiration (e.g. 24h). If the proposal is not verified, the funds will not move (of course)
Attack scenarios- Our multisignature account is compromised:
Since only the active key can be compromiese (owner key is 'very cold') we can remove it from our accounts authority
and place a new one leaving the attacker with a worthless key. - Your active key is compromised:
An attacker would need to also conquer your second factor (currently: email) to have any transaction approved. - Your original account's owner key is compromised:
This will also compromise your secured account since the owner of it is identical to your original account. Hence,
make sure to have your brainkey and owner prive key secured (offline) and only use your active key! Also note, that
you can change the owner account to something else at your own risk.
Known IssuesSince the GUI is not yet capable of producing proposals, we currently only offer a python call that can propose a
transaction as required (see below) Another inconvenience for some users may be that besides proposing a transaction,
users must manually approve their own proposed transaction
There is currently a pending patch for proposing a transaction that needs to be installed into the cli_wallet first:
git remote add graphene https://github.com/cryptonomex/graphene
git fetch graphene
git cherry-pick 7a5c5c4
make cli_wallet
Python library for testingI wrote a new Proposal class to make it easier for people to play around and/or integrate. This class does not yet take
the service fee into account but will do so once we are out of beta.
Installation
git clone https://github.com/xeroc/python-grapehenelib
cd python-grapehenelib
python3 setup.py install --user
pip3 install
pip3 install --user asyncio autobahn requests
Note that you need two active keys installed: a) an active key that can pay for
the proposal and b) the active key of your secured account because you need to
approve your own proposal.
Demo code:
import time
import json
from grapheneapi import GrapheneAPI, GrapheneWebsocket
from grapheneextra.proposal import ProposalManagement
class Config() :
witness_url = "ws://localhost:8090/"
witness_user = ""
witness_password = ""
wallet_host = "localhost"
wallet_port = 8092
wallet_user = ""
wallet_password = ""
proposer_account = "fabian" # this account proposes a proposal
from_account = "fabian-secured" # this is the secured account
to_account = "fabian" # target account
if __name__ == '__main__':
config = Config
## New instance of proposal management
propmang = ProposalManagement(config)
## Propose a transfer transaction on the chain (proposer_account must fund the tx fee)
proposal = propmang.propose_transfer(config.proposer_account, config.from_account, config.to_account, 333.5, "BTS", expiration=60)
## Print the proposal transaction
print(json.dumps(proposal,indent=4))
## Wait for the Proposal to verify on the blockchain
time.sleep(10)
## Approve proposals that require from_account's approval (does not ask for manual confirmation, yet!)
propmang.approve_available_proposals(config.from_account, config.proposer_account)
FAQQ:
Why register new accountsA: For sake of convenience. It is still more difficult for users to set another
active authority than to send funds with a mail address in the memo to a given
account.
Q:
Why is their a public key as owner of the secured account and not my origin account?A: Simply because if it was your account name, anyone with your active key is
owner of the secured account. By putting the owner key of your original
account as owner, your secured account's owner key is "as secure as your
original account".
For those that read through the whole post: Thank you
Hope to hear your thoughts about the over all process!
Cheers
-- Fabian
Show Posts
) I made some modifications to the "standard" in BSIP-1: