Author Topic: [Ann] Peermit.com - 2FA for BitShares (early beta for advanced users)  (Read 11817 times)

0 Members and 1 Guest are viewing this topic.

Offline Thom

+5% Sounds great xeroc!

Glad to see a 2FA scheme not based on cell phones, which a very porous and insecure b/c of the openness at some levels of the comm. stack required for multi-carrier interoperability. That risk may be low, but it is difficult to evaluate. I am very paranoid and would never rely on the security of any 2FA based on cell phones UNLESS I rooted the phone and was very confident of the ROM and other tools to protect the device's security. Even with that, I still have reservations about security compromise at the hardware level.

I presume that the memo field used to communicate the email account is not visible without the transaction private key to unlock?

The use of VPN is great, consider chaining more than one together from 2 or more vendors for added protection.

Consider using a trusted secure email provider like startmail (or setup your own on a VPS) if you haven't already. Only connect to that server via VPN. Email is probably your weakest link in terms of security vulnerabilities.

 :) Oh and condrads on your 10,000th post! I only just recently past 10% of that and got into the triple digits  :)
« Last Edit: December 15, 2015, 04:02:00 pm by Thom »
Injustice anywhere is a threat to justice everywhere - MLK |  Verbaltech2 Witness Reports: https://bitsharestalk.org/index.php/topic,23902.0.html

Offline xeroc

  • Board Moderator
  • Hero Member
  • *****
  • Posts: 12922
  • ChainSquad GmbH
    • View Profile
    • ChainSquad GmbH
  • BitShares: xeroc
  • GitHub: xeroc
Account created.
Building patched cli_wallet.
Need more help on how to create proposal via cli_wallet.
Read the part "Python library for testing" of the announcement. It shows a demo code

Quote
By the way, the owner key and active key of my old account are same, so keys of the new account are same as well, I think it will be problematic..  ::) how to solve?
Yhea .. those accounts are VERY old (maybe even keyhotee founders) .. I can't fix that from my end and decided to still register the accounts accordingly. .
Since you are the sole owner of both accounts you can set your keys as you wish ..
the easiest way would be to update the active key of your original account and only work with that one from now forward ..
make sure to keep the private key for the owner authority as secure as humanly possible

Offline abit

  • Committee member
  • Hero Member
  • *
  • Posts: 4664
    • View Profile
    • Abit's Hive Blog
  • BitShares: abit
  • GitHub: abitmore
Account created.
Building patched cli_wallet.
Need more help on how to create proposal via cli_wallet.

By the way, the owner key and active key of my old account are same, so keys of the new account are same as well, I think it will be problematic..  ::) how to solve?
BitShares committee member: abit
BitShares witness: in.abit

Offline abit

  • Committee member
  • Hero Member
  • *
  • Posts: 4664
    • View Profile
    • Abit's Hive Blog
  • BitShares: abit
  • GitHub: abitmore
BitShares committee member: abit
BitShares witness: in.abit


Offline Riverhead




Looking forward to playing around with this. It is a great use case for the sophisticated key structures offered by Graphene. Awesome work and congrats(?) on your 10 thousandth post!

Offline cass

  • Hero Member
  • *****
  • Posts: 4311
  • /(┬.┬)\
    • View Profile
█║▌║║█  - - -  The quieter you become, the more you are able to hear  - - -  █║▌║║█

Offline xeroc

  • Board Moderator
  • Hero Member
  • *****
  • Posts: 12922
  • ChainSquad GmbH
    • View Profile
    • ChainSquad GmbH
  • BitShares: xeroc
  • GitHub: xeroc
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 Authentication
I 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 users
Providing 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 account
Your 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 Issues
Since 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:
Code: [Select]
git remote add graphene https://github.com/cryptonomex/graphene
git fetch graphene
git cherry-pick 7a5c5c4
make cli_wallet

Python library for testing
I 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
Code: [Select]
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:
Code: [Select]
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)

FAQ
Q: Why register new accounts
A: 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 :D
Hope to hear your thoughts about the over all process!

Cheers
 -- Fabian
« Last Edit: December 18, 2015, 07:38:15 pm by xeroc »