Interesting Decentralized 2FA in a Crypto Currency...

[box0214]

Just read this and sharing. Is there any other altcoin that has 2FA functionality? From my understanding i've always thought 2FA required a centralized party to keep track of the rotating generated pin keys.

I'm writing this quick memo in order to clarify what 2FA is and how is it going to work from the user's point of view.

The two factor authorization (2FA) adds a second authorization with hash chain. The second factor is a hash value that changes with every transaction. This is not a second password (a second password the user can set with the two-phased AC and account voting). 2FA is similar to the transaction authentication number in banking.

Firstly the user must generate a hash chain (preferably on a secured machine). I'll write a tool for that (since I anyways need it to test), but generally this is not part of NRS. I hope to see a more integrated and user-friendly solution for smartphones (actually I may work on that afterwards). The hash chain starts with a cryptographically-secure random secret which is afterwards hashed N times with SHA-256 to receive the last chain value hN(secret) (N is the length of the hash chain). The last value of the chain is provided when creating the account control in NRS. The secret must be stored on the device from where the chain values will be read (this will most probably be the same device where the chain was generated).

When creating the 2FA account control, the user specifies
hN(secret)
Recovery account - where all funds are transferred in case the account password is compromised (what is specified here is actually SHA-256 of its public key)

Once the account control is created, every subsequent transaction is not applied until a special, hash-revealing transaction is received. The hash-revealing transaction reveals the previous hash in the chain - hN-1(secret), hN-2(secret), etc. These values are read from the secured device which contains the initial secret. A tool will display them one-by-one and the user will re-write them or scan them from there.

It is not a problem to have several pending transactions waiting for hash-revealing transaction, but that number must be limited to a reasonable number (else an attacker who knows the account password can waste all account funds in fees).

It is also not a problem to skip one or several hashes from the chain, but up to a reasonable number, else we may end up doing too many calculations.

It is essential the UI to clearly show which transaction will be applied with the revealed hash (i.e. which is the oldest pending transaction).

What should the user do if in the blockchain appears a transaction that he/she does not recognize? At this point new transactions cannot be created because the network cannot know which is created by whom. So we must have set preemptively the recovery data - thus the recovery account when creating the control. Now the user can issue a special Transfer Everything transaction which does not require hash-revealing transaction. It transfers everything to the preemptively specified account.

The recovery account should be specified by a hash of its public key only, not by the actual public key or account number. Only the transfer everything transaction, when submitted, should reveal the real public key of the account to transfer everything to (which should be checked to match this hash).

https://nxtforum.org/account-control/tw ... ion-(2fa)/