The idea to utilize google-authenticator and alike to make wallets more secure isn't a new one yet somehow it doesn't seem to have been implemented anywhere apart from exchanges where the biggest problem is the whole system being compromised and it almost doesn't matter how secure your singular account is.
Let's change that. I'm writing up how I imagine the implementation and integration into NCC so everyone can give feedback and we can hash everything out before we get down to coding.
So what is 2FC supposed to be ?
The idea is to require a 2nd confirmation before a tx is being processed. Using google-authenticator and multi-sig this shouldn't be rocket science to implement.
How does it work ?
To the user it should look like this. Once everything is setup it's always the same when you send a tx from a protected account.
Send a tx -> confirm via google-auth -> tx goes through. If you don't confirm in time the tx will miss it's deadline and vanish from the network.
How does it actually work ?
I imagine the setup process to be like this.
NCC offers the possibility to create a secret for google-authenticator to use. It will tell the user the secrect in form of a qr code and cleartext and the user will set-up google-authenticator on his smartphone using that secret.
Once the user has confirmed that he has stored the secret and set up google-authenticator NCC issues a transaction with the secrect as encrypted message to the "service account" (thus storing it encrypted on the blockchain). The service account is just the account that the service is using it's not a special account or anything.
The service will be monitoring his account and once he sees an incoming tx with an encrypted message it will start listening the blockchain for tx from the sending account. There should prob be a higher fee for this as well so the service doesn't get spammed with a load of fake sign-ups.
How does the service get to confirm tx ? That's where multi-sig comes into play. The service account needs to be a co-signatory of the protected account. This will require m out of n multi-sig (or at least it'll make is way more comfortable).
So once I've singed-up my account is protected. From now on sending txs will look like this.
1) I send a tx.
2) The 2FC service notices the tx and stored the tx-id as "to-be-confirmed" in his db.
3) Once I send a tx and i have 2FC enabled in NCC, NCC will start querying the 2FC service if it's ready to accept a google-auth code. This should be the case as soon as 2) happens. Once it is ready to accept the code…
4)…the user supplies the google-auth code to NCC which will forward it to the 2FC service.
5) If the code is correct the service will co-sign the tx and it'll go through.
The ideal setup would be a 2 out of 3 multi-sig. 2 should be in controll of the user so he can remove the 2FC service from the co-signatories if he wants to and so he can't be removed by an evil 2FC service.
Things to be hashed out…
Does this make any sense ?
Any obvious flaws ?
How hight should the fee for signing up be ?
Would anyone use it ?
PAQ (Probably asked questions)
Q: This is centralized. U mad bro ?
A: This is just a rough first draw-up. Maybe we can decentralize it. Also who cares. If the service is compromised it can't do anything without your funds since you hold the majority of signatures (remember 2 out of 3).
Q: When can we haz thiz ?
A: I don't know. Couple of months ? Depends on priorities.
Q: Could anyone host such a service ?
A: Yes. Obviously this will be open-source and anyone will be free to host such a service. Which is going to be cool since users can choose which service to use and services could even compete with lower fees 'n shit 
I have a few questions that I am not clear.
>NCC issues a transaction with the secrect as encrypted message to the "service account
Why do you need to send that secret? For 2FA operator to note the 2FA?
>The service will be monitoring his account…
Who is "his" account? Service account? What is in the encrypted message content? How is the incoming message sent in? Block Chain?
>1) I send a tx.
>2) The 2FC service notices the tx and stored the tx-id as "to-be-confirmed" in his db.
>3) Once I send a tx and i have 2FC enabled in NCC, NCC will start querying the 2FC service if it's ready to accept a google-auth code. This should be the case as soon as 2) happens. Once it is ready to accept the code…
>4)…the user supplies the google-auth code to NCC which will forward it to the 2FC service.
>5) If the code is correct the service will co-sign the tx and it'll go through.
3) and 4) Is that real time?
What happened to the encrypted message above (i.e., from above…"once he sees an incoming tx with an encrypted message")? What is that for? Is it the code from google-auth?
I have a few questions that I am not clear.
>NCC issues a transaction with the secrect as encrypted message to the "service account
Why do you need to send that secret? For 2FA operator to note the 2FA?
Service and user need to share the secret. That's how google-authenticator works.
>The service will be monitoring his account...
Who is "his" account? Service account? What is in the encrypted message content? How is the incoming message sent in? Block Chain?
Yes service account. The encrypted message contains the secret and yes is ofc sent via blockchain.
>1) I send a tx.
>2) The 2FC service notices the tx and stored the tx-id as "to-be-confirmed" in his db.
>3) Once I send a tx and i have 2FC enabled in NCC, NCC will start querying the 2FC service if it's ready to accept a google-auth code. This should be the case as soon as 2) happens. Once it is ready to accept the code...
>4)...the user supplies the google-auth code to NCC which will forward it to the 2FC service.
>5) If the code is correct the service will co-sign the tx and it'll go through.
3) and 4) Is that real time?
It's as fast as the network propagates tx. Afaik multi-sig txs aren't put in blocks until everyone signed so confirmations won't be necessary.
What happened to the encrypted message above (i.e., from above..."once he sees an incoming tx with an encrypted message")? What is that for? Is it the code from google-auth?
see above. I think you're mixing up the sign-up process with the example I'm describing (in steps 1-5) of a normal tx.
It's as fast as the network propagates tx. Afaik multi-sig txs aren't put in blocks until everyone signed so confirmations won't be necessary.
I think this will be your challenge. 2FA has a 30s(?) time to live. And if it happens mid way or close to end of the cycle, it will time out and you will have lots of issues with missed transactions.
Solution: Modified 2FA with a longer time to live (but you still will have the problem of end of cycle time out issue if it is not properly done, unless you have feedback). Real time direct authentication inside NCC (since this is a central op, it makes no difference to talk directly to the central op.) with the central op.
It's as fast as the network propagates tx. Afaik multi-sig txs aren't put in blocks until everyone signed so confirmations won't be necessary.
I think this will be your challenge. 2FA has a 30s(?) time to live. And if it happens mid way or close to end of the cycle, it will time out and you will have lots of issues with missed transactions.
Solution: Modified 2FA with a longer time to live (but you still will have the problem of end of cycle time out issue if it is not properly done, unless you have feedback). Real time direct authentication inside NCC (since this is a central op, it makes no difference to talk directly to the central op.) with the central op.
I thought of this problem as well. This is actually the reason why it is handled off-chain. I think 30s will be enough because the service seeing the tx isn't when the 30s start.
As soon as the service sees the tx it will store that tx as "to-be-confirmed" at which point it is ready to accept a google-auth-code. It hasn't generated one yet though. When NCC notices that the service is ready (remember NCC is polling the service after sending a tx) it will prompt the user for a code. Once the user has confirmed said code THATS when the 30s start. Since it's just a normal POST from NCC to the service 30s should be more than enough. Once the service receives the post it will generate the code on his end and confirm it.
Also if it fails a retry can happen. The service tells NCC as return value if it was successfull or not. If not then prompt again - rinse repeat.
I chose Google-Authenticator because it seems to be very popular. We could also use other means of confirmation like simply sending one-time-codes that last longer via e-mail or sms.
It is a great idea I think, because it is one step above using multi-signature accounts alone. It is more secure, because the (trusted) phone is needed to send a transaction and not only m (of n) signatures from multi-signature accounts.
The only thing which users have to know: When activating it, they have to be on a trusted computer, because if the "seed" secret (which has to be shared with the phone) is compromised, security is gone.
The "send from offline wallets" idea (https://forum.ournem.com/technical-discussion/sending-transactions-from-cold-wallets/) is still above this idea here, but I would like to see both in NCC, because security is one of the main issues people in crypto. We have a lot of thefts and scams at exchanges - with methods like this, no serious exchange is able to explain any theft and it will be obvious that it was a scam.
The idea […] isn't a new one yet somehow it doesn't seem to have been implemented anywhere apart from exchanges […]
Take a look at NeosCoin, I think they are doing similar stuff. Not 100% sure though.
It is a great idea I think, because it is one step above using multi-signature accounts alone. It is more secure, because the (trusted) phone is needed to send a transaction and not only m (of n) signatures from multi-signature accounts.
The only thing which users have to know: When activating it, they have to be on a trusted computer, because if the "seed" secret (which has to be shared with the phone) is compromised, security is gone.
The "send from offline wallets" idea (https://forum.ournem.com/technical-discussion/sending-transactions-from-cold-wallets/) is still above this idea here, but I would like to see both in NCC, because security is one of the main issues people in crypto. We have a lot of thefts and scams at exchanges - with methods like this, no serious exchange is able to explain any theft and it will be obvious that it was a scam.
The idea [...] isn't a new one yet somehow it doesn't seem to have been implemented anywhere apart from exchanges [...]
Take a look at NeosCoin, I think they are doing similar stuff. Not 100% sure though.
I hadn't even thought of that but I guess exchanges could run their own 2FC service. That would actually be pretty sweet.
I think it is completely possible to build a google 2FA directly into NCC and that the 2FA doesn't ever touch the NIS or blockchain. That is basically how exchanges do it.
A person goes to send a transaction and NCC could push it through, it already has the private key, but it won't until a 2FA is given. If I remember right, one the original NXT wallets that flopped before Wesley became dominant might have had that feature.
At that point if somebody gets your password for you wallet, or if you leave NCC open and go get a cup of coffee, you are still okay, but if somebody steals your private key, it is game over.
I like the idea of some kind of blockchain based 2FA but that is much more difficult to implement I guess. I personally am doing my own sort of 2FA in that I have my account set up being multisig and one of the keys is on an Ubuntu stick, so to make any transaction go through I have to plug in an ubuntu stick and sign then.
To that end if somebody wanted to set up a 2FA third party service, then I guess that is possible and while it would be nice to use Google 2FA, it wouldn't have to. It could also work via text message and I think it would actually be easier that way.
The way I would do it is that you agree to let a third party centralized service be a signer on a multisig account. When you send a transaction they are watching the block chain and when they get a notice to sign, they send you a text and/or email. The text and/or email says something like, "A transaction has been initiated on your account, click here to approve, or click here to decline and report this transaction." Then a person just clicks on the correct link in an email or text. No Google 2FA needed. I have thought about this sometimes and this is the easiest method I can think of and is basically the same method exchanges are using.
But again, if you could figure out a way to make a blockchain based decentralized Google 2FA, that would be awesome.
I think it is completely possible to build a google 2FA directly into NCC and that the 2FA doesn't ever touch the NIS or blockchain. That is basically how exchanges do it.
A person goes to send a transaction and NCC could push it through, it already has the private key, but it won't until a 2FA is given. If I remember right, one the original NXT wallets that flopped before Wesley became dominant might have had that feature.
That's not nearly as secure as combined with multi-sig since it's completely client-based.
...
The way I would do it is that you agree to let a third party centralized service be a signer on a multisig account. When you send a transaction they are watching the block chain and when they get a notice to sign, they send you a text and/or email. The text and/or email says something like, "A transaction has been initiated on your account, click here to approve, or click here to decline and report this transaction." Then a person just clicks on the correct link in an email or text. No Google 2FA needed. I have thought about this sometimes and this is the easiest method I can think of and is basically the same method exchanges are using.
...
That's exactly what I'm proposing only with email instead of Google Authenticator. Like I said, the service could offer all kinds of confirmation methods besides Google Authenticator. Google Authenticator is just very popular which is why I'd implement it first.
I wouldn't want the email thing though. Once I find out someone is using that service (not hard since the sign-up is on the blockchain) tricking him into clicking a malicous link will be a walk in the park.
Step 1: I see someone has signed up.
Step 2: I'm watching for transactions.
Step 3: Once I see one I'm sending him an email with an evil-link. Most users won't look twice at the link once they are used to the service. With a little luck my email arrives first and the user will click on my evil-link.
Also the mails should be encrypted which makes the set-up a lot more inconvenient to downright impossible for non-tech people.
here are my second thoughts and here is how I would propose it.
New features are built into NCC to create a 2FA account (not google but only NEM blockchain based). When somebody makes a 2FA NEM account the account is set up as multisig. There are different combinations and ways to make this happen such as 2/3 or 3/3 or 4/4, but I'll just explain 2 of 3 since it is similar to Pats.
When a person sends a transaction on NCC one of the 3 signers has signed, and now we need a second. At this point a person has a special stripped down NEM app on their phone. The person then opens their app and it asks them, "would you like to sign" and then person says yes. The special 2FA stripped down NEM phone app then signs the 2nd signature and the transaction gets pushed through.
here are my second thoughts and here is how I would propose it.
New features are built into NCC to create a 2FA account (not google but only NEM blockchain based). When somebody makes a 2FA NEM account the account is set up as multisig. There are different combinations and ways to make this happen such as 2/3 or 3/3 or 4/4, but I'll just explain 2 of 3 since it is similar to Pats.
When a person sends a transaction on NCC one of the 3 signers has signed, and now we need a second. At this point a person has a special stripped down NEM app on their phone. The person then opens their app and it asks them, "would you like to sign" and then person says yes. The special 2FA stripped down NEM phone app then signs the 2nd signature and the transaction gets pushed through.
That just basic multi-sig usage which will prob be possible right away once the mobile app is out. No stripped down version needed imho.
It's a very valid point though. Once we have the mobile-app it's way easier to just have one of the co-signatories on the app (assuming the app behaves like NCC regarding multi-sig).
Nice. Saves me a load of coding ;D
here are my second thoughts and here is how I would propose it.
New features are built into NCC to create a 2FA account (not google but only NEM blockchain based). When somebody makes a 2FA NEM account the account is set up as multisig. There are different combinations and ways to make this happen such as 2/3 or 3/3 or 4/4, but I'll just explain 2 of 3 since it is similar to Pats.
2FA on blockchain will be too slow.
When a person sends a transaction on NCC one of the 3 signers has signed, and now we need a second. At this point a person has a special stripped down NEM app on their phone. The person then opens their app and it asks them, "would you like to sign" and then person says yes. The special 2FA stripped down NEM phone app then signs the 2nd signature and the transaction gets pushed through.
This would be multisig in action. We could do that on the mobile app.
I chose Google-Authenticator because it seems to be very popular. We could also use other means of confirmation like simply sending one-time-codes that last longer via e-mail or sms.
e-mail, don't think it is a good idea.
2FA, as long as there is feedback for status, should be a better way forward.
About the 2AF, I wrote up on git hub ( https://github.com/NewEconomyMovement/NemCommunityClient/issues/218 ) my experience with the 2AF for 2 years using this tecnology.
Initial question:
hi there.
Is it possible to have the 2AF or TFA for NCC ( maybe between NIS and NCC togheter… who knows)?
https://www.dshield.org/diary/How+To%3A+Setting+Up+Google's+Two-Factor+Authentication+In+Linux/16270
http://www.neowin.net/forum/topic/1060788-linux-two-step-authentication-with-pam-and-google-authenticator/
http://www.blackmoreops.com/2014/06/26/securing-ssh-two-factor-authentication-using-google-authenticator/
thanks a lot and have a nice day!!
=]
And I did a comment:
My perception over this function, as I use 2AF (two authentication factor) more than 2 years:
Strong points:
[li]More effective account protection, as the codes changes every 10 seconds;[/li]
[li]Possible utilization for the harvesting on others machines, as you don
Honestly I think using multi-sig and the mobile app is the best and most convenient 2FA we're gonna get. No need for an additional implementation imho.
Honestly I think using multi-sig and the mobile app is the best and most convenient 2FA we're gonna get. No need for an additional implementation imho.
Yup. And all on the block chain. ;)
Honestly I think using multi-sig and the mobile app is the best and most convenient 2FA we're gonna get. No need for an additional implementation imho.
Yup. And all on the block chain. ;)
Yes, the more I think about it multisig plus NEM app is a great 2FA. In some ways better because it is a 2-way 2FA. With a google app, it doesn't initiate, it just confirms. With NEM you could start or confirm.
Honestly I think using multi-sig and the mobile app is the best and most convenient 2FA we're gonna get. No need for an additional implementation imho.
Yup. And all on the block chain. ;)
Yes, the more I think about it multisig plus NEM app is a great 2FA. In some ways better because it is a 2-way 2FA. With a google app, it doesn't initiate, it just confirms. With NEM you could start or confirm.
It is the better way without doubt. But there are many many non tecnical users, and user who do not wish or can understand the MultiSig.
Precisely for this target group would be interesting the Google 2fa or Authy app.
Honestly I think using multi-sig and the mobile app is the best and most convenient 2FA we're gonna get. No need for an additional implementation imho.
Yup. And all on the block chain. ;)
Yes, the more I think about it multisig plus NEM app is a great 2FA. In some ways better because it is a 2-way 2FA. With a google app, it doesn't initiate, it just confirms. With NEM you could start or confirm.
It is the better way without doubt. But there are many many non tecnical users, and user who do not wish or can understand the MultiSig.
Precisely for this target group would be interesting the Google 2fa or Authy app.
This is also a good point. It's important to make things easy for the average user. We need to target the 7 billion people out there.
I'm not completely sure how to use authy or google with NEM other than it be added to the NCC. And even then, as it would just be a 2nd layer password on NCC.
I'm sure that would be a pretty easy feature for somebody to add to NCC though and it wouldn't hurt.
The other option is to make an alternate version NCC and alternate version mobile app that together worked like the authy does with websites. That would be solid security feature that would make NEM very hard to compromise and be easy for people to use, but would require more serious coding.