BLS keys (the ones used for wallets) are already multisig out of the box.
They’re better than bitcoin multisig because with bitcoin there’s a (soft) limit of 3 party multisig, whereas bls has no (practical) upper limit.
in bls 50-of-70 is indistinguishable from 2-of-3 which is indistinguishable from 1-of-1 which is indistinguishable from ‘normal’ keys.
bls keys and signatures are the same size no matter how many parties are involved, so they have same size on the wire/disk and the same cpu cost for verification, unlike bitcoin where more complicated scripts are large in size and take longer to verify.
bls keys are pretty amazing. There’s a reason so many projects are using / moving to them (eth2, zcash, algorand, chianet and probably many others too).
Setting a side the credential recovery side of things, which is related I’ll grant you, and focusing on the MFA, I’d be minded to see what we suite we could put together from the…
Something You Know
Something You Have
Something You Are
…triad.
If we take it that we have the ‘Know’ part covered with the password + passphrase combo, then we give a number of options on the second two it suit the threat model of the individual; allowing them to balance added security against against added friction, while choosing a solution that’s gonna work for their situation.
A mobile device or software solution might not work for someone who is always jumping between pubic desktop computers for example, a FIDO might be great for that. Likewise, if I’m predominantly on mobile a USB key is gonna be pretty useless.
I also wouldn’t dismiss biometrics, as not everyone is facing physical threats, and using that can allow them to strengthen the ‘Know’ elements, for increased security from remote threats. And often of course it’s often combed with something you Have in the form of an iPhone etc.
Having a device is not good for Safe goals because Safe is meant to be able to be used even if you are unable to have anything with you but you can find a computer to use. EG house burns down and you do not have a device for doing 2FA, there is no one who can reset things when you answer a series of questions to verify you to the site owner. So why not have Safe do the asking of those questions. ← trying to brain storm here
My issue with this is how do you point to an individual Safe/Account without some element like a password?
It feels like this would only weaken things by either allowing an individual to be specifically targeted through a public identifier, or just softening up the whole thing through a series questions which are perhaps more inherently knowable by a 3rd party?
The thought would be a series of questions need to be asked. Say from different categories. The answers unlock part of an encryption key. So if 5 categories then only correct answers to each provide 5 x 32 byte key. Any one part or even 4 parts is insufficient to brute force the 5th part.
Then these 5 parts together unlock the second key required to log on. So you need the actual password and this unencrypted key that the 5 parts together decrypted.
This could actually be done within the client and could become a much more secure secure system that some may want.
And as said before could be adapted to be an account recovery tool.
I’d expect that this would require a second account set up to be unlocked by answering questions and not for normal account. Its purpose is to store a key encrypted by the 5 parts. Answering a question will not provide a clue if the answer was right or wrong. So even if someone tries it.
Now brain storming this we could have say the Network incorporate a number of 2FA algorithms and the users selects which is suitable for their device. Then instead of being personal questions they could be codes that need to match up with the network’s calculation.
This comes to mind whether it be a device one uses or questions answered. Both can be used to get control of an account
But what is the reason for having the 2FA, to make it hard for others to access your account. We already have something like this
Even adding 5 easy questions we have made it near impossible for some random to break your account unless they have a keylogger.
Guess what even with googles 2FA that has a 30 second window, a key logger can gain access in a second. So 2FA is actually easily broken if you can get a keylogger installed. So is 5 questions close to a 2FA device? Well no if the person knows who you are and gets your password. So have we defined exactly what is being asked for here. Is 2FA the best way to go? While better than a series of questions is it what would be best for Safe over 20+ years?
The majority of security breaches happen remotely though. That’s why I was emphasising a multi factor approach that can be tailored to the threat model.
But by having any element of the scheme which is public information, you increase the chances of both remote and physical threat.
I’m not quite sure whether you are suggesting this second bit though. I wouldn’t be in favour of it though.
But I’m saying that what you’re proposing isn’t 2FA.
It’s just more of one factor with a leaning toward softening the whole thing, because by prompting people to provide answers to questions, perhaps makes it more likely to for them to unwittingly create credentials that are known, or can be deuced by other individuals without the need to brute force.
For Safe we will have both seeing as its so long term. Access to the person allows control of the 2FA device as well as manipulating the passphrase out of the person. Smart keylogger allows access to account and 2FA answer remotely. And with google 2FA you have the 30 second window to use it
And I agreed already. I suggested that maybe launching from this idea we could get to implementing 2FA along those lines where the network is asking questions that only the 2FA device can answer. It is similar to asking personal questions.
So maybe (remember brainstorming here) we could have personal questions be one of the methods along with say google’s 2FA method, along with a rolling code system, along with ??? system. The user decides what they want to use. (EDIT: when setting up their account)
Maybe also then (still brain storming) the 2FA querying (actual 2FA) could be incorporated with an account recovery mechanism that then asks an additional 10 (or more) questions that all have to be correct (or 10 out of 15) which then unlocks the original password. The 2FA will stop any random brute forcing since it is required before the questions are known.
Brute force on the Safe network is another issue that I think will not be a great issue since the lag time will limit the number of attempts per second. So a reasonable password or questions/answers would protect to some extent since brute force only allows a max of a few tries per second. (Around 100-200K per day)
I wonder how that will go when one thing that Safe tries to achieve is being able to access your account from any computer which also implies you may not have you 2fs device with you.
You have to have a smartphone capable of the NFC thing though, so it’s not a panacea.
Another option might be a paper-based token. Could be as basic as keys to a shell/container for the Safe proper, which you then open with your regal credentials. Could be a QR code to scan etc. Again, just a brainstorm!
Several options for these factors might provide a solution which is adaptable to various situations.
Keep a QR code in your wallet, or a set of one-time codes etc, but have a Fido on your keychain for convenience, or wrap it up in a biometric for speed on mobile.
Would be good to have a hardware device that signs stuff for a session so that you could minimize damage done when logging in through a compromised computer.
Imagine you are at an internet cafe and you want to open some files, you could then choose either to allow access to everything, a specific file, folder etc for either read or write access.
When transfering tokens each transaction could be seen on screen on the hardware device and must be signed there.
In this way damage would be minimal if you were at a compromised computer. Whatever files you were reading or gave access to might be siphoned off, but not everything.
I like that idea as it’s all on the network. The less dependency on external widgets, dongles and keys that may or may not be available in your country the better. Maybe optionally allow biometrics to be used to create / verify the auth account too.
This can be solved by not using a common area, but using messages to an ID owned by the respective account. Not normal ID but one for the purpose of authorisation meaning any non authorising messages can be ignored.
Maybe also then (still brain storming) the 2FA querying (actual 2FA) could be incorporated with an account recovery mechanism that then asks an additional 10 (or more) questions that all have to be correct (or 10 out of 15) which then unlocks the original password. The 2FA will stop any random brute forcing since it is required before the questions are known.
Asking personal questions may not be suited to 2FA but they are perfect for account recovery. I would guess most ordinary users are probably more likely to forget their password than to get successfully attacked by hackers, so to my mind account recovery would be more useful than 2FA for most people.
I wonder if there are any stats for things like Bitcoin about which incurs more losses: lost passwords or hackers.
I think we should separate these two things for the purposes of this discussion, even though the mechanisms may share some overlap. Both are highly desirable, but it shouldn’t be one over the other.
The immediate things that jumps out at me here is a requirement for data to be written to the network for this to function. If the token balance runs out on the auth wallet, are you locked out? Do you have to top it up some how before you can log back in? Or does it just remain at the last generated code/data when the balance runs to zero, making it less secure?