Author Topic: [ANN] Peermit 2-Factor-Authentication deployed in the TESTNET!  (Read 7280 times)

0 Members and 1 Guest are viewing this topic.

Offline rnglab

  • Full Member
  • ***
  • Posts: 171
    • View Profile
  • BitShares: rnglab

Offline GChicken

  • Sr. Member
  • ****
  • Posts: 231
    • View Profile
Great effort Xeroc!, got my 2fa TX done; had to have a few goes at it before i worked out what was required; place i got stuck are 1st and foremost skimming through the original OP.. ;/

i initially thought it would be similar to what arhag suggested, propose TX from 2fa protected wallet and then approve via email to have peermit sign and finalize the TX, i guess the issue here is if i have owners authority of that account and the wallet was compromised then as the 'owner' it can just disable the 2fa ; and pinch my precious test coins. - is that correct?

once i had a better grip on what was needed, i missed the '+' button on the email similar to roadscape, seem the register button just need a check to ensure that email address is present (i.e the '+' button has been clicked)

Account:
REF:j0shy
SECURE:j1mb0

then i proposed a TX from j0shy which transferred 1234 test from j1mb0 to j0shy. i received an email at sharklasers email account (getting pretty excited at this stage ). clicked link, verified the token; and waited in j0shy account for something to happen... nothing; then from j0shy account i viewed j1mb0 account and could see a pending transaction awaiting approval from j0shy (this maybe more protocol level but isn't the fact that j0shy proposed the TX infer that he also approves the TX??). Clicked approve and added authority from J0shy accepted WOOHOO! :)

seem like a few steps involved to get it functioning but it works and is very cool :)  +5% Xeroc!
looking forward to seeing if there is a method to simplify the process similar to arhag suggestion i.e send from account, verify with link in email, done. but again i think the issue here is if the account has owner permission it can just disable 2fa before stealing the coins..

Offline xeroc

  • Board Moderator
  • Hero Member
  • *****
  • Posts: 12922
  • ChainSquad GmbH
    • View Profile
    • ChainSquad GmbH
  • BitShares: xeroc
  • GitHub: xeroc
Quote
2016-04-11 13:18:20,068 - monitor - WARNING - 1.10.68: Our approval required but we don't know user lock-it-down (1.2.463)
Have you added your mail address and clicked the "register" button?

Yes, it gives the message "Successfully updated your settings: Registered". I'm testing with a sharklasers.com email address.
 
Oh .. I see ..

you need to select the Mail addres, paste your address THEN click on the "+" sign and then click on Register ..
The reason for this rather click-intensive setup is that it allows to later add different account-specific settings as well ..
such as .. also use this maill address, temporary allow transfers without 2FA, and I could even ask for your identification and improve the whole system for whitelisting and KYC/AML (maybe) ..

Offline roadscape

Quote
2016-04-11 13:18:20,068 - monitor - WARNING - 1.10.68: Our approval required but we don't know user lock-it-down (1.2.463)
Have you added your mail address and clicked the "register" button?

Yes, it gives the message "Successfully updated your settings: Registered". I'm testing with a sharklasers.com email address.
http://cryptofresh.com  |  witness: roadscape


Offline abit

  • Committee member
  • Hero Member
  • *
  • Posts: 4664
    • View Profile
    • Abit's Hive Blog
  • BitShares: abit
  • GitHub: abitmore
And just to add my two cents on the discussion for issue 556, I think it makes sense that the active authority can change active permissions. I don't agree with pc that it makes the distinction between owner and active useless. The way I think of it, the owner keys are just meant to be stored offline as a backup mechanism to get back control of your account even if your (hot) active keys are compromised. Actually, one other thing that I think might make sense to only allow owner keys to do is to transfer the account name. Your account name might be very valuable and you likely have no way of getting it back if it was stolen from you. If you could transfer it using only the active authority, then a compromise of your hot wallet could mean the loss of your account name. At least with asset transfer risk you can limit the potential financial loss by limiting the amount of assets you store with the account.
There is another serious issue about owner/active authorities: https://github.com/cryptonomex/graphene/issues/635

Haven't check the dedicated "account_transfer_operation" though.
BitShares committee member: abit
BitShares witness: in.abit

Offline arhag

  • Hero Member
  • *****
  • Posts: 1214
    • View Profile
    • My posts on Steem
  • BitShares: arhag
  • GitHub: arhag
For now, I think it doesn make sense to give people even more options
but I will certainly look into it! Thanks for the feedback!!

Sure, I agree it is best not to give users too many options. So if I had to pick one I would say avoiding the proposed transaction feature of the blockchain and instead communicating txs and signatures between 2FA provider and user directly would lead to better UX and get around some of the existing limitations of the blockchain like issue 479. Happy to hear you are considering it though.

Totally, this has been on my list for quite some time and with the
option to use this for 2FA, I might implemented it sooner than thought.
Now that I learned quite a bit about the internal mechanisms of the web
wallet, it might even not take so much time.

Thanks for your feedback, much appreciated!!

Fantastic. Thanks for all of your work!


@arhag FYI there are several know issues in Graphene core and UI which made things a bit messy:

Thanks for those list of issues @abit.

* https://github.com/cryptonomex/graphene/issues/479 why proposer doesn't approve the proposal by default

I see that backreference IDs were chosen to not be implemented in Graphene. So as it stands, atomically creating and approving a proposed transaction is not possible. That's too bad. Even more of a reason to use an out-of-band method for 2FA multisig rather than proposed transactions. It would make the UX for the user so much better.

* https://github.com/cryptonomex/graphene-ui/issues/721 Current GUI always require owner authorities while voting

Oh good. So the voting issue I encountered is a GUI bug and not a protocol bug. And just to add my two cents on the discussion for issue 556, I think it makes sense that the active authority can change active permissions. I don't agree with pc that it makes the distinction between owner and active useless. The way I think of it, the owner keys are just meant to be stored offline as a backup mechanism to get back control of your account even if your (hot) active keys are compromised. Actually, one other thing that I think might make sense to only allow owner keys to do is to transfer the account name. Your account name might be very valuable and you likely have no way of getting it back if it was stolen from you. If you could transfer it using only the active authority, then a compromise of your hot wallet could mean the loss of your account name. At least with asset transfer risk you can limit the potential financial loss by limiting the amount of assets you store with the account.
« Last Edit: April 12, 2016, 02:28:46 am by arhag »

Offline abit

  • Committee member
  • Hero Member
  • *
  • Posts: 4664
    • View Profile
    • Abit's Hive Blog
  • BitShares: abit
  • GitHub: abitmore
@arhag FYI there are several know issues in Graphene core and UI which made things a bit messy:
* https://github.com/cryptonomex/graphene/issues/479 why proposer doesn't approve the proposal by default
* https://github.com/cryptonomex/graphene/issues/442 why no notification to potential signers when a new proposal proposed
* https://github.com/cryptonomex/graphene/issues/636 why GUI doesn't know if a full or partially signed transaction has enough signatures
* https://github.com/cryptonomex/graphene-ui/issues/255 unfinished feature: generate key pairs in GUI
* https://github.com/cryptonomex/graphene-ui/issues/721 Current GUI always require owner authorities while voting
* another issue yet to be submitted to github: unable to add signatures to a partially signed transaction with current CLI
BitShares committee member: abit
BitShares witness: in.abit

Offline tbone

  • Hero Member
  • *****
  • Posts: 632
    • View Profile
  • BitShares: tbone2
Good stuff, @xeroc.  And your receptiveness to incredible feedback from @arhag will help make this the best solution it can possibly be!

Offline merivercap

  • Hero Member
  • *****
  • Posts: 661
    • View Profile
    • BitCash
Fantastic job @xeroc!  Definitely look forward to working with you and using this service!  +5%
BitCash - http://www.bitcash.org 
Beta: bitCash Wallet / p2p Gateway: (https://m.bitcash.org)
Beta: bitCash Trade (https://trade.bitcash.org)

Offline xeroc

  • Board Moderator
  • Hero Member
  • *****
  • Posts: 12922
  • ChainSquad GmbH
    • View Profile
    • ChainSquad GmbH
  • BitShares: xeroc
  • GitHub: xeroc
The second way to do 2FA is for the user's client to pass the partially signed transaction to the 2FA provider and have the provider sign it (after verifying authority using 2FA) and broadcast the fully signed transaction. This method avoids the overhead of proposed transactions and allows the user to use just their one account. Graphene's proposed transactions are incredibly useful when you have more than one signing parties that are regular users and not services provided by a business. But in the typical setup for 2FA, you have one regular user and one business. The signaling and communication protocol to carry out multisig in this case is simple enough that Graphene proposed transactions are not necessary.

Billiant idea. I'll try to figure something out. The foundations I have
developed for this approach can certainly be reused to improve it and
also offer an alternative way.
For now, I think it doesn make sense to give people even more options
but I will certainly look into it! Thanks for the feedback!!

Quote
So now for some problems I had with the current implementation of 2FA using proposed transactions. It was hard to follow your guide. I'm pretty sure I didn't end up following the exact procedure you meant for us to follow due to vagueness of the guide. It would be better if you went through an example using actual account names rather than "secured account" and "reference account". I also ended up having both accounts in one wallet for convenience. I am not sure if that is what you intended. I created a proposed transaction that was payed for by my arhag2 reference account to send 300,000 TEST from my arhag1 secure account to arhag2. After creating this proposed transaction, nothing happened. I went to my arhag1 account in the wallet and discovered that the proposed transaction had not been approved by either secured-by-peermit or arhag2. I don't see why the client doesn't automatically approve using the reference account when I create the proposed transaction using the refernce account. I was forced to create yet another transaction to approve the proposed transaction using arhag2. This entire UX needs to be streamlined so that some of these implementation details are abstracted away. Anyway, I wasn't able to actually get it to work because the proposed transaction I created is still waiting to be approved by seecured-by-peermit, but I haven't received any email at all. Nevermind, it worked. I turns out the email went to my spam folder.
Thanks for the feedback. I do recognize that setting up the secured
account is still way to complicated and I need to work on it, but I
wanted to get something out and show people some progress.
The UI stuff is easy to tune over time once the backend and foundations
are done, which they are by now.

Quote
The other thing I would like to see is for the 2FA authentication to be optionally done using TOTP. It is much easier for me to read a 6 digit one-time code off my smartphone and type it into the BitShares wallet than it is to deal with emailed links for every single transaction. This can be an authentication mechanism for lower stakes transactions. The 2FA provider can provide limits on how much funds can be transfered in some time window using authentication by TOTP alone. For higher stakes transactions, email links + TOTP could be used so that the user can get feedback from the provider about what transaction they are approving (in case their desktop computer is compromised for example).
This will be added eventually. Any proposal could carry a second
"transfer" operation that carries the TOTP in the memo (encrypted for
peermit's eys only of course). But I am not there yet.

Quote
Edit: BTW, I think we need the following additions/utilities. The GUI wallet should have a mechanism of creating and perhaps partially signing but not broadcasting a transaction which can be saved to a file. It should also have a mechanism to read a (perhaps partially) signed transaction from a file, presenting the transaction to the user, adding any extra signatures it can and then broadcasting it to the network. We then need a nice offline utility to: 1) generate new public key/private key pairs; 2) deterministically generate private keys from a brain key + passphrase and import them into a temporary wallet session; and, 3) read a transactions from a file, presenting it to the user, adding any signatures it can, and then saving the signed transaction to a file. This way, the offline utility can sign transactions that change the secure account's owner and active permissions without ever exposing the owner keys of the secure account to an internet connected computer.
Totally, this has been on my list for quite some time and with the
option to use this for 2FA, I might implemented it sooner than thought.
Now that I learned quite a bit about the internal mechanisms of the web
wallet, it might even not take so much time.

Thanks for your feedback, much appreciated!!

Offline arhag

  • Hero Member
  • *****
  • Posts: 1214
    • View Profile
    • My posts on Steem
  • BitShares: arhag
  • GitHub: arhag
I just came across another annoyance (bug? feature?) in Graphene that I never realized before. Apparently changing your votes requires owner permissions instead of active permissions? I tried setting a proxy voter for my arhag1 account using a proposed transaction. However, it did not require approval from arhag2 and secured-by-peermit as I expected it would. It required approval by the owner key of the arhag1 account. Because I changed the owner key of arhag1 to a key that the wallet did not have access to, I was unable to approve that proposal. So I had to manually import the owner private key and then approve the proposed transaction to set the proxy. I then deleted my wallet and created a new one from the brain key to go back to a state where the wallet does not have the owner private key stored locally (for security reasons). Now that arhag1 proxies to arhag2, I can change votes directly with the arhag2 account without needing to make any more account changes to arhag1. But I find it frustrating that I had to use an owner key to change my votes in the first place.

Am I correct in understanding that this is a limitation placed by the blockchain itself? If so why? Is it intentional or is it a bug? Do we need to change the protocol through a hard fork to allow vote changes to be authorized by either owner or active permissions rather than only owner permissions?

Also, what happens if I proxy to an account that proxies to another account? Will the vote weights follow to the terminal account? If not, the limitation above is even more problematic. Let's say I want to proxy my vote weight to xeroc, but I want to be able to easily choose another account to proxy to at a later date. I can set arhag2's proxy to xeroc. But if I set arhag1's proxy to arhag2, then its stake won't count in the vote if the proxying is not transitive. If I proxy arhag1 to xeroc directly and then later decide to change the proxy, I will be forced to not only change the proxy on my arhag2 account (which is no big deal) but also the more troublesome arhag1 account. That requires going through the inconvenient and insecure process of importing an owner key to a hot client (or alternatively if we had offline transaction signing then it could be done securely but still inconveniently) to change the proxy on the arhag1 account. So if proxy voting is not transitive, I would consider the above limitation a bug. And even if it is transitive, I still think it makes sense to make the change anyway because if active permissions can steal all the funds of the account then it makes no sense for changing votes to require any more restrictive/secure permissions.
« Last Edit: April 11, 2016, 06:56:57 pm by arhag »

Offline arhag

  • Hero Member
  • *****
  • Posts: 1214
    • View Profile
    • My posts on Steem
  • BitShares: arhag
  • GitHub: arhag
Nice job xeroc! But I do have some criticism.

The way I see it there are two ways to do multisig on Graphene.

The first is to use proposed transactions the way you have done here. You have a secured account whose funds are protected by multisig, and you have a reference account that can create transactions using only the private key stored locally in the user's wallet. The secured account's active authority requires signatures from both the reference account and the 2FA provider. The reference account is needed to create and submit the proposed transaction to the blockchain.

This method has some advantages:
  • The signaling to the 2FA provider is done through the blockchain which (maybe?) simplifies the interaction between user and 2FA provider.
  • The user can hold funds securely in the secured account but can also hold some funds in the reference account that can be spent without the extra overhead of 2FA. The funds in the reference account are at risk of being stolen if the user's wallet is compromised, but if the user only keeps small amounts in the reference account for temporary convenience, this may not be a big issue.

But it also has disadvantages:
  • There is additional blockchain bloat required for each transaction. And though these would likely be rate-limited free transactions, there is still some cost to the overhead for example through the opportunity cost of using the bandwidth allocation for other free transactions. And the 2FA provider needs to broadcast a proposal approval transaction to the blockchain. How will they pay for this overhead (say through the opportunity cost of holding enough BTS so they have sufficient bandwidth available to serve their customers)? They might have a policy of only approving transactions that  pay them a small fee. Or they might just slightly increase their monthly subscription fee that they expect users to pay them for their service. Either way, a profitable business acting as the 2FA provider will somehow pass on this overhead cost to the user.
  • It requires the user to setup two different accounts. Perhaps users don't care about the flexibility of having an account that they can spend some funds without 2FA required. In that case, dealing with two accounts just adds extra cognitive burden to the user.
  • If the reference account runs out of funds to pay fees, it is no longer possible to even propose a transaction to move funds from the secured account to the reference account despite the fact that the user has plenty of funds in the secured account to pay the fees. I ran into this problem myself when using the testnet. Check out the transaction history for arhag1 and arhag2 to get a sense of the problem I ran into. I needed to create a new account i-messed-up to just get free money from the faucet to transfer to arhag2 so that arhag2 could pay the fee for a proposed transaction.

The second way to do 2FA is for the user's client to pass the partially signed transaction to the 2FA provider and have the provider sign it (after verifying authority using 2FA) and broadcast the fully signed transaction. This method avoids the overhead of proposed transactions and allows the user to use just their one account. Graphene's proposed transactions are incredibly useful when you have more than one signing parties that are regular users and not services provided by a business. But in the typical setup for 2FA, you have one regular user and one business. The signaling and communication protocol to carry out multisig in this case is simple enough that Graphene proposed transactions are not necessary.

I would love to see 2FA providers allowing both options to be available for users. But I think the second approach is the simpler one that users should be pushed towards by default.



So now for some problems I had with the current implementation of 2FA using proposed transactions. It was hard to follow your guide. I'm pretty sure I didn't end up following the exact procedure you meant for us to follow due to vagueness of the guide. It would be better if you went through an example using actual account names rather than "secured account" and "reference account". I also ended up having both accounts in one wallet for convenience. I am not sure if that is what you intended. I created a proposed transaction that was payed for by my arhag2 reference account to send 300,000 TEST from my arhag1 secure account to arhag2. After creating this proposed transaction, nothing happened. I went to my arhag1 account in the wallet and discovered that the proposed transaction had not been approved by either secured-by-peermit or arhag2. I don't see why the client doesn't automatically approve using the reference account when I create the proposed transaction using the refernce account. I was forced to create yet another transaction to approve the proposed transaction using arhag2. This entire UX needs to be streamlined so that some of these implementation details are abstracted away. Anyway, I wasn't able to actually get it to work because the proposed transaction I created is still waiting to be approved by seecured-by-peermit, but I haven't received any email at all. Nevermind, it worked. I turns out the email went to my spam folder.

The other thing I would like to see is for the 2FA authentication to be optionally done using TOTP. It is much easier for me to read a 6 digit one-time code off my smartphone and type it into the BitShares wallet than it is to deal with emailed links for every single transaction. This can be an authentication mechanism for lower stakes transactions. The 2FA provider can provide limits on how much funds can be transfered in some time window using authentication by TOTP alone. For higher stakes transactions, email links + TOTP could be used so that the user can get feedback from the provider about what transaction they are approving (in case their desktop computer is compromised for example).

Edit: BTW, I think we need the following additions/utilities. The GUI wallet should have a mechanism of creating and perhaps partially signing but not broadcasting a transaction which can be saved to a file. It should also have a mechanism to read a (perhaps partially) signed transaction from a file, presenting the transaction to the user, adding any extra signatures it can and then broadcasting it to the network. We then need a nice offline utility to: 1) generate new public key/private key pairs; 2) deterministically generate private keys from a brain key + passphrase and import them into a temporary wallet session; and, 3) read a transactions from a file, presenting it to the user, adding any signatures it can, and then saving the signed transaction to a file. This way, the offline utility can sign transactions that change the secure account's owner and active permissions without ever exposing the owner keys of the secure account to an internet connected computer.
« Last Edit: April 11, 2016, 06:01:29 pm by arhag »

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 xeroc

  • Board Moderator
  • Hero Member
  • *****
  • Posts: 12922
  • ChainSquad GmbH
    • View Profile
    • ChainSquad GmbH
  • BitShares: xeroc
  • GitHub: xeroc
Quote
2016-04-11 13:18:20,068 - monitor - WARNING - 1.10.68: Our approval required but we don't know user lock-it-down (1.2.463)
Have you added your mail address and clicked the "register" button?