2 Factor Confirmation Proposal

Project Proposals
#1

The original thread can be found here.

The 2FC is an old idea in NEM, and I’ve thought a specific implementation that I want to share it with you guys.

The project goal is create a system/process to secure a user account when he/she has to add the private-key (and public-key as well) to be able to use a third-party software. The third-party software may not be a open-source project, or may has evil purposes.

The project includes:

  1. Create a multisig account process (2/3)
  2. NEM Authenticator, a mobile app for Android & iOS
  3. NanoWallet Module

It is fully decentralized, so no third-parties are involved and it doesn’t need a Web Service running to work!

The project proposal details can be found at Google Docs. It is an early stage version, the current version is v.1.1. It may change based on feedback, keep updated.

I’m looking forward to listen your feedback! :grin:

Technical Reference v.1.3

CHANGELOG

16/05/17 - v1.2

  • Added NanoWallet Module specification
  • Added Failure Scenarios
  • Added Multisig Account Limitations

18/05/17 - v1.3

  • Removed Web Service
  • Removed TOTP Services
  • Added NEM Authenticator component
  • Medium post for non-technical people
  • Updated post content
1 Like
NEM Authenticator - Be a beta tester
#2

The idea, and the original idea that patmaster proposed in the forum, is sure interesting. Though i would need to spend some time on gasping the details.

#3

I’m considering the next failure scenarios:

Scenario: A Co-Signatory run out of XEM

Given the Main Account or 2FC Account
When it has less than 6 XEM
Then it is stored in a local database to retry the transaction later
And an error message is displayed describing the error and the solution

Scenario: The transaction expires

Given a transaction that expires in X seconds,
When it has not been signed in the available time,
Then it is stored in a local database to retry the transaction later
And an error message is displayed describing the error and the solution

Scenario: The TOTP service is unavailable

Given a new unsigned transaction and a valid TOTP code,
When the Web Service cannot reach the TOTP service to verify the code,
Then it is stored in a local database to retry the transaction later
And an error message is displayed describing the error and the solution

#4

Multisig Account Limitations

AFAIK, a multisig account cannot be a co-signatory of other multisig account. So, the system will create the 2FC Account from scratch and then convert it into a multisig account (2/3).

This process ensures the correct 2FC configuration.

#5

Listening the community feedback, and I’m aware that there are people currently working in a similar solution. I will check out the document proposal.

An implementation is currently being developed by @gevs , you can found it here. It’s not a 2FA, but it’s similar :slight_smile:

1 Like
#6

following scenario is possible right now with my bot:

  • in the bot config you must add the multisig address.
  • in the bot config you add the priv key and cosignatory account address

anytime a tx is announced for that multisig, the bot will cosign for you. currently there is no check on the origin of the tx etc… but thats all to be added of course (cosignatory, tx creator auditing)

for a succesfull 2FA, whzt do you guys think we would need? @deleted_user_1 @kodtycoon :slight_smile:

#7

I’ve updated the document (v.1.3), pending to add more specific details, removing the Web Service and the TOTP algorithms.

The multisig account configuration is the same, but the web service is replaced by a mobile application (called NEM Authenticator for marketing purposes).

#8

Currently the set up I have is a bot that’s deployed to a windows machine by the user. You enter the cosignatory private key (or keys, supports any amount of cosignatories). There is no need specify the Multisig account as that’s requested via the blockchain. You can enter white list account, black list accounts, max tx per day, week, month, max tx size singular, max tx volume per day week month, secret code (though I can’t fix the encrypted messaging still so that’s going to have to be hidden for now or use one off messages). Think there may be one or two other rules I can’t think of right now.

The one rule set is applied to all cosignatories/Multisig accounts. If you add a cosignatory that’s already logged in the config to a new Multisig account it’s automatically scanned.

Ive got a lot of ideas for this but will just see what happens. The second iteration I’m thinking of adding api’s to allow programmatically adding and removing cosignatories and custom rule sets per cosignatory/per Multisig account. But still trying to think how best to do it.

#9

Cool! Ping us when the bot is production ready! Or you want some testers :wink:

#10

you can test it now if you like. ill pm you

#11

@kodtycoon, my bot publishes an API too, I think it gives the “deployer” an easier approach at least for my bot where the communication is done over websockets or the blockchain… I thought about a read only API for my bot, but maybe something can be merged from your bot when it is ready, I would like to have a look at it if possible :slight_smile:

#12

This is a much better approach in terms of security and manageability than my original proposal. It’s actually how I operate right now, only I use the normal nem mobile-app to do the co-signing.
My proposal came, I think, pre-n-of-m-multi-sig being available and was more focused on using something people already know i.e. google authenticator.

#13

isn’t multisig already a blockchain auth?

#14