Update 4 November 2021

[JimCollinson]

@isntism

How about adding the date and time of account creation as a default third access key or is that too easy to brute force?

I’d have to think about how much extra entropy that would add, probably very little, especially by comparison to the extra hassle factor of entering it.

@isntism

I’m doubting that ‘normal’ people are actually going to be remembering a list of words

The Password is the bit you remember. There is no expectation that you would remember the Passphrase. That is something you have, you write it down, print it out and store it safely. You can make more than one of course, and store them in separate locations.

(I mean, you could remember it if you wanted to, in extremis, such as if you needed to flee a conflict zone, and you could take no belongings, and it’d be way easier to do than the equivalent random raw key. But these are extremes).

@isntism

they’ll just plaster their QR codes all over the place or only have a screenshot of it on the phone

We actually make it way easier than that for them! That’s what a device key is for, a small file that is stored on their phone, so they only need to type in their Password. In fact, if they want, they could put this Password behind a biometric such as FaceID… so they really want, all they need is their phone, and their face!

@isntism

the phone they will inevitably lose.

Ah… that’s where the Passphrase comes in! If they lose their phone, they can can get back in using the Passphrase they printed off (there will be a QR on the printout too, so they won’t need to type anything), and their Password. But if they forgot that, they could go and retrieve the other Passphrase they stashed at Granny’s house and they are back in.

Mucha flexibilidad!

[dask]

It’s a beautiful system where everyone can decide their own security/redundancy parameters and change them on the fly… a bit akin to horcruxes. Very impressed with it tbh.

[happybeing]

@JimCollinson

But it would also be trivially easy for us to program the app to just nuke the device key after say 10 failed attempts;

Not sure this solves it. An attacker won’t brute force via an app, they’ll fire things at the network so I think the counter measures would need to be in the core and I’m not sure that’s practical or at least effective.

You’d need to rate limit attempts to unlock per device, which implies time or a way to introduce a delay or a counter that renders brute force ineffective but doesn’t lock any other devices out. Sounds challenging!

[JimCollinson]

@happybeing

Not sure this solves it. An attacker won’t brute force via an app, they’ll fire things at the network

Ah right, I see what you are saying, they’ve stolen the phone/computer, and managed to bypass any device encryption (such as the PIN/biometric) and have access to the device key. They’d then be brute forcing the Password only. So yeah, in that circumstance, you’d want to have created a password that was strong enough to withstand that attack until you could get on the Network via another device and revoke the device key.

This would be an attack with a reasonable amount of sophistication I guess; the attacker would need access to the device, the PIN, and the capability to brute force in reasonable time. But yeah, possible. And if that’s a concern, perhaps I’d be looking at not saving the device key, or having another hardware device in the mix for a 3-of-N. And of course as you say, a decent password, the sort of which you’d use for your password manager etc.

All depends on your individual threat model.

@happybeing

a way to introduce a delay or a counter that renders brute force ineffective but doesn’t lock any other devices out. Sounds challenging!

I’ll let others chime in here I think! @mav is going to do a deep dive into the mechanisms behind these designs in the coming weeks which I think you’ll all enjoy, and I’m sure he’ll have some additional insight.

[dlux]

A big congratulations to you @JimCollinson and @joshuef!

[Traktion]

Congratulations @JimCollinson and @joshuef! Really great to see such valued members of the team being recognised. Glad to see we continue to be in safe hands (pun intended! )!

[happybeing]

@JimCollinson

All depends on your individual threat model.

Of course, but with Safe we are potentially talking about a lot of highly valuable and sensitive information. For a start it’s a bank account, but much more than that, we want people to move their lives into this platform because it is secure.

Anyway, my point is that this is something that we need to understand so we can make the best UX, minimise risks etc.

[Michael_Hills]

@happybeing

Anyway, my point is that this is something that we need to understand so we can make the best UX, minimise risks etc.

It should all be tied to a heat emanating fingerprint, so that the only way to hack the account is for the hacker to force the safe holder to open it, at gun point. In this case all you need is a really good lock on your front door, and speed dial 911.

Congratulations to @JimCollinson and @joshuef for your well deserved promotions, and great UX!

[Bernhard_Rekkedal]

Congratulations @JimCollinson and @joshuef. Nice to see a positive update, without bugs!

[jlpell]

@drehb

In BIP-39 the terminology used is mnemonic,

Also, isn’t the password essentially the same thing as a mnemonic seed extension at this point? (From the user perspective)

Regardless, I think the password/passphrase terminology is best for the layman. The phrasing is simple and straightforward and can be extended easily. For example, the hardware device described above could be called a ‘passkey’ to fit within the same paradigm. Simple to grok for just about anyone… the user needs to supply 2/3 of their password/passphrase/passkey to access their safe etc. Looking good Maidsafe. The only other thing on my wishlist would be simple low-level a mechanism for one-time-pins (OTP). Literally a list of pre-generated “pass-pins” would do. I suppose that might be on the horizon though with your mention of a yubikey.

[Blindsite2k]

This is great though I think it needs to be further simplified for the “older generation” and tech noobs unfortunately. I’m constantly having to explain to my Mom how to log into Google and exasperated by her not being able to remember her password. In some ways her writing ALL her passwords down is a good thing. But at the same time she would get terribly confused by things like a Bip39 based passphrase. That would have to be explained. Using biometrics is tricky as some phones don’t read fingerprints all too well, especially if you use screen protectors (like mine). But the concepts above are promising. I just think there needs to be more noob friendly tutorials.

[anon23746431]

@maidsafe

are ergonomic

Is “ergonomic” the biometrics? It’s like a touch ID and a face ID.

[neo]

@maidsafe

There will be kinks to work out, undoubtedly, such as recognising and handling password typos

I am sure there are many codes that allow for error correction. Even simple ones like the various ECC codes for system memory. Maybe a PIN allowing one or more chars to be corrected. Its optional and can be public so written on the device. Its information is about 2 to 4 or 6 chars worth, I suspect, reduction in the password/passphrase but will solve the typos in a 64+ character entry.

So much in what you wrote I will have to reread when I get back from my short trip.

Congrats to @JimCollinson @joshuef for their promotions.

Sounds like setting up the deck chairs for greater things to come.

@happybeing

Anyway, my point is that this is something that we need to understand so we can make the best UX, minimise risks etc.

Brute force will really only be effective if the attacker can obtain the account record and do brute force off line to the Safe Network.

Otherwise there will be at least 100mS per access. Max read attempts would be less than 1 million attempts per day per instance. More like 200mS

Thus the attacker needs to run multiple clients attempting to read account record.

It is a good point though. But once the account record has been read then its brute (or otherwise) attack on a piece of data. At that point the various methods to access the record only can mean quicker access, but without them it is attacking a encrypted block of data trying to decrypt it.

So the real protection lies in the address of the account data being as protected as the decryption key.

[TylerAbeoJordan]

Well, all sounds amazing as usual - par for the team of course!

On the access method @JimCollinson , for those of us who are good at remembering complex passphrases. Will it still be possible to jump on ANY device (even generic never used before devices) and simply gain access to our accounts? That was sort-of a dream of mine with Safe. To have essentially dumb terminals with SN installed and to just be able to log in with no traces on the machine before or after.

[joshuef]

Thanks everybody!

[dugcampbell]

Nice one @JimCollinson and @joshuef! Well deserved both of you

[JimCollinson]

@jlpell

Also, isn’t the password essentially the same thing as a mnemonic seed extension at this point? (From the user perspective)

It’s actually not the same as the BIP39 extension (if that’s what you’re asking).

In our case the Password, Passphrase, Device Keys, and any additional access keys you create are all individual KeyShares that can be used in a variety combinations to unlock your Safe.

The BIP39 approach binds the mnemonic and extension together—on is useless without the other—and that won’t fit our requirements as both elements would always be required. So it becomes more cumbersome to use, and would be intolerant of credential loss.

@jlpell

For example, the hardware device described above could be called a ‘passkey’ to fit within the same paradigm. Simple to grok for just about anyone… the user needs to supply 2/3 of their password/passphrase/passkey to access their safe etc.

This is actually not a bad shout. I’ll have to think that through though, as we’ve been using the umbrella term “Access Keys” to describe these elements… so there may be a confusing overlap there.

@Blindsite2k

This is great though I think it needs to be further simplified for the “older generation” and tech noobs unfortunately. I’m constantly having to explain to my Mom how to log into Google and exasperated by her not being able to remember her password. In some ways her writing ALL her passwords down is a good thing.

Yes it’s hard, isn’t it? There isn’t a simple solution. There is a certain level of entropy required to avoid people getting ripped off, it’s all a matter of how that is packaged, and managed.

I think we have a step forward here, because we are providing for times when folk forget their passwords. And also that for many people, the best thing to do would be to have a strong randomly generated credential, that they write down, plus another factor.

In your mum’s case, let’s walk through what that might look like, and see if it could work for her.

• If you could help her create a strong password, that would be useful, although if she is prone to forgetting, then perhaps she can rely more on the Passphrase
• So she could print out her passphrase, and use this as her main credential. The printout will have a QR, so after tapping the enter key button, she could just scan it, and not have to worry about phrase entry
• If she has a PIN set up on her phone, then a saving the device key could be a good shout. In this case, she’d then just unlock her phone, then scan the printed QR and she’s in.
• Then you could also walk her through creating and printing an additional Passphrase which you could store for her, should she misplace her one.

And that’s not touching on additional device keys that could help out too.

@anon23746431

Is “ergonomic” the biometrics? It’s like a touch ID and a face ID.

Ergonomics is to do with how humans will interpret, handle, and enter keys. Biometrics might be part of it, but another part is making things pronounceable, readable, and reliable to type.

So this would be a un-ergonomic key:
xprv9s21ZrQH143K4Da9L5beiCu3f5LhWmDztZHP8QMSCBQTZoMjXdH9FPLHqBJiuXxAqyRU8HnQ4dwiz7SSr4gtGTJkUXc4m1x6TbQVnxMuz5n

Hellish to use.

But here is an ergonomic equivalent of that key:
wing reward sniff flip snake fork discover truck advance sadness slim cash

They have the same end result, but one can be used reliably, and we can make it waaaay faster and more understandable to input. It even has a checksum at the end so I know if I’ve made a typo. The wordlist construction means I won’t even need to fully type each word either!

In short, same thing, but way easier to use. And this is just one aspect of the ergonomics of the overall system.

[JimCollinson]

@neo

I am sure there are many codes that allow for error correction. Even simple ones like the various ECC codes for system memory. Maybe a PIN allowing one or more chars to be corrected. Its optional and can be public so written on the device. Its information is about 2 to 4 or 6 chars worth, I suspect, reduction in the password/passphrase but will solve the typos in a 64+ character entry.

Specifically we are talking about the suer chosen password, and how we handle typos on that (the passphrase is fine, as we have a checksum on that). But it’s only an issue in certain circumstances.

When the device has been used before, we can store a hash of the password locally, alongside the device key say, and check it against that and give the user some immediate feedback.

If, though, I’m unlocking on a new device for the first time, there is a bit more of an issue, because there is no immediate way to detect the difference between a typo in the password, and the need for additional keys to unlock… we can give subtle hints to say “check your password”, but it would be nicer if we could say for certain that there is a typo.

@TylerAbeoJordan

for those of us who are good at remembering complex passphrases. Will it still be possible to jump on ANY device (even generic never used before devices) and simply gain access to our accounts?

Yes, absolutely. You don’t need to rely on any device keys at all.

The simplest setup would be a Password + Passphrase, and you are good to go. (Although, I’d still probably recommend having additional key stored somewhere, just in case.)

It’s not for everyone, but actually it’s not as tricky as you might think to memorise a 12 word phrase like that, should you need to. And I have to say the BIP39 wordlists have been cleverly constructed to aid with that.

[nowfeelsafer]

Is this mechanism for logging in something that is planned for day 1 launch, or something that will be implemented at a later stage. The feature looks really good and like all things done by maidsafe really well thought out and innovative, but I am just concerned it could end up delaying further the launch. I imagine we could - during the period when we will interact with the network only with a CLI - live with just a password and passphrase.

(I hope this comment is not taken the wrong way; I am a big supporter of the project like many here)

[TylerAbeoJordan]

@JimCollinson
Just thinking out loud here. I currently use QTox for messaging. it’s peer to peer and end to end encrypted. I believe something very similar can be done on SN.

1. if it can, then could it be created such that you don’t have to have an SN account to use it?
2. if #1, then perhaps such could be used to create an account by first getting together with trusted friends (who already have accounts? or simultaneously create them) using the SN messaging app and then with a click or three creating an account that shares backup keys with your friends.

While it sounds like extra complication, I think it could be easier in some ways for those who want to back up keys OR alternatively create a joint multisig account.

Just a random thought anyway, don’t know if it’s reconcilable with what you’ve already thought of.