BitShares Forum
Main => General Discussion => Topic started by: xeroc on April 11, 2016, 10:35:07 am
-
After quite some coding, refacturing, cleanups and more refacturing of
processes as well as with the great progress made by jcalfee1 and svk, I
am proud to show the first minimum viable product for Peermit
2-Factor-Authentication in the testnet.
This gives you a free way to play around, setting up a secured account
and learning how things will most probably be deployed also on the main
network and hopefully gives me some material and feedback that I can use
to improve the UI and the backend code.
This is how it works:
1) Create a new account on http://testnet.bitshares.eu
2) Create a new "secured" account
3) Make a backup to secure the owner key that will give ultimate access to your account
4) Unlock your wallet
5) Open the Permissions page of your account and click on the tab "2FA"
6) Provide a mail address that shall be used to contact you on proposals Click on the "register" button and wait for confirmation from the API server
7) Provide a reference account name (a secondary account that you have control over) that has to also approve any proposals Click on the little 'add' button and don't wonder that your account name disappears afterwards
8) Enable 2 Factor Authentication
9) Finally publish the changes made to your account
No you can essentially delete your newly created wallet that contains only one
(secured) account and for which you have a backof of the owner key.
If you open up your regular wallet, you can now open the account page your your
secured account and propose a transfer from that account (e.g. the initial 1M
TEST).
Once you have proposed that transfer, you should receive an (currently ugly)
email with a link to peermit.com. After providing the secret token (similar to
poloniex) to peermit.com, we will approve your transfer.
All that is left is that you reference account ALSO approves that transfer. To
do so, open the secured account. You should see the proposal below the list of
assets. Click on "Approve" and add your approval from the corresponding
accounts.
After that approval transaction has been confirmed, the transfer will be
executed.
Happy testing. I am looking for plenty of constructive critisism.
Cheers
-- Fabian
-
+5%
-
+5% +5% +5% :)
-
+5% :D
-
I think I like this. Usually 2FA involves a cell phone account (a means to tie real world ID to an ID in virtual space). If I understand this correctly the 2nd factor in the approach you outline here is just another BTS account owned by the same person as the account you wish to secure. Not everyone uses a cell phone, or one tied to a verifiable, real world ID so this approach avoids that concern as well as preserving pseudo anonymity.
Do I have your 2FA approach correctly framed here xeroc?
-
+5% +5% +5%
-
Built into the wallet now.. nice!! +5%
I tried to propose a tx, but I get: "Missing Active Authority 1.2.463". Strange, 1.2.463 is the account I just created (lock-it-down). I did verify that I have a 2nd authority and the threshold is 2.
-
I think I like this. Usually 2FA involves a cell phone account (a means to tie real world ID to an ID in virtual space). If I understand this correctly the 2nd factor in the approach you outline here is just another BTS account owned by the same person as the account you wish to secure. Not everyone uses a cell phone, or one tied to a verifiable, real world ID so this approach avoids that concern as well as preserving pseudo anonymity.
Do I have your 2FA approach correctly framed here xeroc?
It's about right. Yes. My lawyer is of the opinion that (once I formed a
legal Peermit entity), I don't need to know real world identities just
to provide this service.
As for PhoneID and other means of second factor verification, I do plan
to add other communication channels, such as maybe SMS, Telegram chat,
IRC or maybe later even add QR-code verification (little tricky) but
before doing so, I need to make sure the core functionalities are
stable.
-
Built into the wallet now.. nice!! +5%
I tried to propose a tx, but I get: "Missing Active Authority 1.2.463". Strange, 1.2.463 is the account I just created (lock-it-down). I did verify that I have a 2nd authority and the threshold is 2.
You need to propose a transfer from ANOTHER account.
Also note that you have not added a reference account to your lock-it-down account.
This account shows you how things should be looking (take a look at the ACTIVE permissions tab):
https://testnet.bitshares.eu/#/account/tesaf11/permissions/
I will work on making it more clear that
a) you need a regular account as reference that can create proposals for the secured account and
b) you need to have the reference account added to your active permissions .. which is what step 2 in 2FA does
-
Built into the wallet now.. nice!! +5%
I tried to propose a tx, but I get: "Missing Active Authority 1.2.463". Strange, 1.2.463 is the account I just created (lock-it-down). I did verify that I have a 2nd authority and the threshold is 2.
You need to propose a transfer from ANOTHER account.
Also note that you have not added a reference account to your lock-it-down account.
This account shows you how things should be looking (take a look at the ACTIVE permissions tab):
https://testnet.bitshares.eu/#/account/tesaf11/permissions/
I will work on making it more clear that
a) you need a regular account as reference that can create proposals for the secured account and
b) you need to have the reference account added to your active permissions .. which is what step 2 in 2FA does
Ok, now I was successfully able to propose a transaction, but I don't see an email yet. (`roadscape` proposed for `lock-it-down` to send 10,000 TEST to `faucet`)
-
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?
-
+5%
-
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 (http://tools.ietf.org/html/rfc6238). 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.
-
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.
-
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!!
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.
The other thing I would like to see is for the 2FA authentication to be optionally done using TOTP (http://tools.ietf.org/html/rfc6238). 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.
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!!
-
Fantastic job @xeroc! Definitely look forward to working with you and using this service! +5%
-
Good stuff, @xeroc. And your receptiveness to incredible feedback from @arhag will help make this the best solution it can possibly be!
-
@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
-
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 (https://github.com/cryptonomex/graphene/issues/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 (https://github.com/cryptonomex/graphene/issues/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.
-
And just to add my two cents on the discussion for issue 556 (https://github.com/cryptonomex/graphene/issues/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.
-
Woah, awesome !!!
-
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.
-
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) ..
-
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..
-
This is owesome.
I'll be testing asap.