Two Factor Authentication (Multi-sig)

[kcole16]

Overview

Adding support for multi-sig based 2FA will make the web wallet more secure. This will require deploying a contract to wallet users' accounts, and will allow them to specify which transactions require multi-sig.

Stories

As a user, I want to set limits on my transaction amounts, requiring two factor authentication above the limits, so I can use the web wallet to safely store $100-$1000 worth of assets.

Flows

For any account, there are minimum three keys

1 key in localStorage 1 key in recovery 1 key on our server

TXs require 2-of-3 multi-sig

Create account with 2FA

1. User receives Linkdrop link
2. User enters desired account name on /create
3. User chooses how to "Secure Account" a. Use Ledger only b. Setup SMS-based 2FA, choose email or seed phrase recovery
4. createAccount function on Linkdrop contract is called
   1. Up to 3 keys are passed as arguments to be added as multi-sig keys a. If Ledger, only one key is passed and multi-sig is 1-of-1 b. If 2FA, backend generates a key to be added to multi-sig, returns to frontend
   2. In a batch TX a. Account is created b. Multi-sig contract is deployed, with keys as multi-sig keys c. Keys are added as access keys (separate from above) d. Account is funded (if applicable)

Sign TX with 2FA

1. User initiates a TX, signs with key in localStorage
2. Server sends an SMS to the user with TX details, code to enter
3. User enters the code into the UI
4. Server signs and sends TX

Recover with 2FA (Email)

1. User clicks link in recovery message
2. User is redirected to /recover-with-link
3. Selects "Continue"
4. Uses Sign TX with 2FA flow to finish recovery

Recover with 2FA (Seed)

1. User navigates to /recover-seed-phrase
2. User enters account name and seed phrase
3. Selects "Continue"
4. Uses Sign TX with 2FA flow to finish recovery

[ilblackdragon]

Specifically, I think final version of this can look:

• One key is inside secure enclave on the phone / keychain on laptop
• One key is on centralized service of users choosing that provides 2FA
• One key is split into parts and distributed among friends / contacts for social recovery Where 2 out of 3 is required to sign. (This can be customized, like can use more than one centralized service, including can send one key to email but this has it's own attack vectors)

This addresses all the attack vectors:

• Sim swap and identity swap (like SSN + last name in banks :( ), where centralized service would be fooled but still need to get either to user's unlocked device or be able to convince friends.
• Friends colluding, won't be able to get 2FA from centralized service.
• Lost phone, can recover via
• Indirect attack with malicious software on the device, would still require 2FA

[bowenwang1996]

@ilblackdragon what if friends collude to steal your phone 😂

[kcole16]

Expanding on @ilblackdragon's comments:

Goals

Prevent attackers from

• Gaining access to keys
• Manipulating the user into signing a bad TX (e.g. don't have the key, but change the UI)

Flow

For any account, there are minimum three keys

• 1 key in localStorage
• 1 key in recovery
• 1 key on our server

TXs require 2-of-3 multi-sig

1. User initiates a TX, signs with key in localStorage
2. Server sends an SMS to the user with TX details, code to enter
3. User enters the code into the UI
4. Server signs and sends TX

cc @vgrichina @Patrick1904

[mattlockyer]

This is great. My only concern earlier when we discussed this was with:

4. Server signs and sends TX

If it's a contract needing a second signature only, it should be fine. The server key must not have any ability to do anything except be a second signature.

Questions

What if the user needs to recover their account? Are we requiring recovery key + server key? Or is the recovery key just another version of the local storage key that we sent to them?

Lastly, because we sent them the recovery key (probably a seed phrase that recreates the localstorage key???), we probably should make certain that we've scrubbed all record of this from our servers, email servers, logs, etc... Since we technically have the 2/3 we need at some point in time. I'm still not happy about sending a recovery key in plaintext. At the very least we should throw a weak encryption around the recovery phrase based on a PIN and some client side JS.

Proposals

WRT keys to generate locally:

• 1 key generated client side
• 1 copy is kept in local storage
• 1 copy, as seed phrase, is "weakly" encrypted with a client provided PIN and PBKDF2 with tons of rounds, all of which can be decrypted using a static HTML/JS page, if there is no Near Inc.
• The encrypted seed phrase is emailed to them as a recovery option
• Near Inc. does it's best to scrub all records of this encrypted data from it's servers / mailservers (having this data means potential brute forcing)

The second remote key:

• 1 2FA key is generated on the Near server
• we'll need some storage opsec of these keys against exfiltration, get these and no more 2FA making a hack on high value targets trivial

[vgrichina]

What if the user needs to recover their account? Are we requiring recovery key + server key? Or is the recovery key just another version of the local storage key that we sent to them?

There needs to be 2 options: 1) normal recovery flow (recovery link key + our 2FA key) 2) gain full access when NEAR 2FA isn't accessible but you still have local storage key (local storage key + recovery link key).

At the very least we should throw a weak encryption around the recovery phrase based on a PIN and some client side JS.

such encryption doesn't add security (brute-forcing PIN is trivial unless it is unpractically long), but would degrade UX by a lot.

Note that as Illia outlined above (https://github.com/near/near-wallet/issues/423#issuecomment-623090551) in ideal security scenario there is no key in local storage / e-mail at all. However we can implement it only for mobile apps. Casual web wallet users have to accept bigger security risks, but this is fine as they aren't expected have a lot of value to start with. Once they have more value on account – we should steer users toward more secure options (mobile app, Ledger, etc).

we probably should make certain that we've scrubbed all record of this from our servers, email servers, logs, etc...

agree with this 100%, we need to make sure SendGrid/Twilio doesn't keep message bodies.

[kcole16]

Two questions:

1. Can Ledger be used without multi-sig? a. I'd say it certainly should be used without, but we'll need to account for that in the contract design
2. We will need the user to enter their phone number. Should we remove this as an option for recovery? Or even combine the two? (Definitely tradeoffs to the latter)

[kcole16]

Expanding on Create account with 2FA

1. User receives Linkdrop link (can discuss how this works when going directly to wallet later)
2. User enters desired account name
3. User chooses how to "Secure Account" a. Use Ledger only b. Setup SMS-based 2FA, choose email or seed phrase recovery
4. createAccount function on Linkdrop contract is called
   1. Up to 3 keys are passed as arguments to be added as multi-sig keys a. If Ledger, only one key is passed and multi-sig is 1-of-1 b. If 2FA, backend generates a key to be added to multi-sig, returns to frontend
   2. In a batch TX a. Account is created b. Multi-sig contract is deployed, with keys as multi-sig keys b. Keys are added as access keys (separate from above) c. Account is funded (if applicable)

cc @mattlockyer @ilblackdragon @vgrichina @corwinharrell @Patrick1904

[Patrick1904]

Closing as issue is outdated