In the future, one might have a significant amount of private information and wealth stored on the Safe Network. Loss or compromise of account credentials could be devastating to the account owner. In this thread, let’s brainstorm Safe-centric ways to achieve two-factor or multifactor authentication. Any other unconvential schemes to protect authentication credentials are also welcome.
Not 2FA per se, but for loss, what about using a 1 of 3 or 2 of 6 multisig/password system. I’m assuming Safe will have multisig at some point if it’s not already in the cards for beta. So one could store the other spare password/signatures in multiple safe locations as they wouldn’t need them except as backup if something happened to the first.
“At its core, FIDO2 consists of the Client to Authenticator Protocol (CTAP) and the W3C standard WebAuthn, which together enable authentication where users identify themselves with cryptographic authenticators (such as biometrics or PINs) or external authenticators (such as FIDO keys, wearables or mobile devices) to a trusted WebAuthn remote peer (also known as a FIDO2 server) that typically belongs to a website or web app.”
Reliance on a specific hardware wallet or hardware key is problematic imo. In general, the 2fa concept just requires a software program/app running on a different device than the one used for a login attempt so the process should be hardware agnostic. Maybe that could be one of these devices if they offer a basic linux stack/libraries to support, but most people would prefer a phone. What do you do when you lose your phone or hardware key/device? This process is not ideal.
Biometrics based methods are a danger to the account owner.
Something more clever is necessary.
This article does a good job of laying out the pros and cons of things like hardware wallets and offering a possible solution which seems to offer a way forward. I hadn’t come across social recovery wallets before.
The social wallet recovery article is basically a rehash/promotion of multi-sig benefits, with a built-in cooldown period where large transactions can be cancelled.
The edge case that was not covered in detail is what happens if the ‘guardians’ collude? (They did mention the possibility of giving assigning keys to people that don’t even know that they are a guardian until you request assistance. What if those blind guardians refuse to assist?)
Doesnt have to be the only way. HW key is one input and the system could be n-1 of n. If the HW key gets lost/destroyed/stolen and you have/know all the other inputs, you are still in the game.
You use your recovery seed to restore your access using another device. That’s still the state of the art in the crypto world anyway. Multi-sig setups are starting to become more prevalent and easy to use these days, but again each device will be based on some seed that must be backed up offline.
With the current design of SAFE though I’m not sure how to make this work for login. It think at least for the coin transfer signing it can work.
The point I was trying to bring up was not so much a technical one as it was cost based. ie. now you need to buy another (expensive) mobile device.
Something like a usb key might be cheap enough to have many…
Got it. Well I think the idea has always been that it would be an optional thing for additional security. Very much like how crypto wallets can just be software that runs on a regular computer, or one of these more secure hardware devices.
“This should be considered as “no-brainer” as they come. Why? Because by adding two-factor authentication, it becomes exponentially more difficult for malicious users to gain access to your machines”
Maybe you could look towards a system where personal questions could be answered by the user and encrypted with the account as an associated blob. You do not log directly into your account but the network challenges the secondary blob with your password and it unlocks a series of questions that can be asked.
The challenge is being asked the question requiring an answer. Thus the secondary blob has a different password to the account and the passphrase is being built. So one could use the actual password to account thus no 2FA, or use password for secondary blob and answering questions then allows login to main account. This would be useful in say internet cafe etc
While not perfect it is having to know something personal to you.
Once the question is answered it unlocks the password to the account which is then used to unlock the user’s account.
Maybe this might not be the best for 2FA it would give possibilities for account recovery where the secondary blob allows the person to not remember the passphrase but by answering the series of personal questions the password is being built in the client and then used.
I think you are on to something here. However personal questions are tricky and the recovery blob would need to be well constructed. You would be surprised about how much personal information is out there in the public domain that could be used. I applied for a financial account a few years back and as part of the process needed to answer a series of personal questions to prove it was me. They already had all the answers to all the common questions one could think of for a recovery blob.
Correct, I suggested as perhaps something could be developed from the idea.
For account recovery it would require correct answers to a minimum of 5 or perhaps 10 questions and no indication of bad answers since the blob would not know anyhow.
To summarize, we have a couple different use cases and potential techniques related to MFA.
- Account recovery → multisig, smart blobs
- Unauthorized account access → oob 2fa, otp, hardware key
- Theft of credentials in transit-> otp, hash chains
The other main challenge I see is in keeping the account locator / passphrase secure. Say they are both cryptographically strong 256bit seeds. Everyday use of the network means they will be stored on an internet connected computer. You are going to need to keep them encrypted most of the time (usually with a less secure password). Are these actually going to be transfered as part of self authentication?