Safe authentication considerations

[drehb]

It isn’t for 1 vs 2 words, but there was some analysis of complexity requirements from Trezor here:

What’s up today? (Part 1)

Comparism of different ways to make strong password

[oetyng]

@JimCollinson

This is a side topic really, but I don’t think the user should need to silo these different usecases into separate accounts.

There could well be the facility in future to have different account ‘profiles’, for different contexts.

But we should be working to facilitate the ‘1 Unique Human = 1 Account’ UX. With all that SAFE enables, the user shouldn’t need to have multiple accounts and multiple passwords (probably then having to rely on a single password manager), any more than they’d need to have multiple brains.

This post here is what made me see your angle.

I think the problem here is the use of the word ‘Account’.
We are used to have an account for everything. Hundreds of them (or more??). I am 100% sure you see how that taints the solution you intend for it. The language is very important.

The word ‘Account’ brings in that whole world right from the very beginning.

This is not an account, it’s the entry to a new world. A portal to a parallel dimension It probably needs a fitting name, so that people realise what it is. If you really intend for it to be 1 entry to this world per user, and within that world there is an ocean of possibilities to create accounts or identities, then the word Account doesn’t quite do it.

Edit: Hey, @JimCollinson , what do you think of this? Does it resonate with you or spark any ideas? (Although, as you say, this is a side topic here.)

[tfa]

@JimCollinson

On a side note, something that has come up regularly in Usability testing is people not really understanding what “Account Secret” means.

…

So, we are testing alternative labels for that. Front runner is “Passphrase”, so you’d create a Passphrase and Password , during on-boarding.

Don’t you think that there is a bigger problem than just a label, but rather that 2 strong names are simply too unusual.

But I will repeat again my main question: will @maidsafe implement account location based on the 2 elements?

This question is more important than what the official authenticator will do about the strength and the name of the first element because this would allow alternative authenticator forks interoperating the same way to the network but with different philosophies than yours:

• with a weak first element like a username or a common name

• or even with no visible first element at all (implicit empty string) to implement connection with only a password as suggested by some.

[TylerAbeoJordan]

There is an opportunity here I think … this debate between one or two secrets/pass/word/phrases … If we allow the user upon creating their ‘account’/‘next-dimensional-portal’ to select HOW they want to access it … with one two or three or more pass-what-evers … and then we give all users the opportunity to put in as many or as few as possible … then we add a new layer misdirection for attackers, while simultaneously giving options to users.

I ASSUME in all of these options that when an account is created that there will be a test of the access method to determine it’s level of complexity and security and to subsequently deny the account creation if it isn’t sufficient.

[dirvine]

@TylerAbeoJordan

to select HOW they want to access it

Then it will be a single password and a simple one. That is the empirical evidence so far. If we look at common password lists etc. It is no an easy thing if we decide to allow very simple starting points. I am not saying you are saying that, but the initial start has to be very secure IMO then added security options.

[TylerAbeoJordan]

@dirvine

and a simple one.

@TylerAbeoJordan

I ASSUME in all of these options that when an account is created that there will be a test of the access method to determine it’s level of complexity and security and to subsequently deny the account creation if it isn’t sufficient.

Simple == denied.

Maybe this is all too much to ask of the team to worry about right now … maybe this will develop as it moves from beta to 1.0 I’m not a serious coder, so I don’t know. I think options are always good though.

[neo]

@tfa

But I will repeat again my main question: will @maidsafe implement account location based on the 2 elements?

Isn’t this part of the client code. In other words anybody could have there own system if they can get it programmed by themselves or another. You could even have a client with the address hard coded (bad I know but its possible)

The best I like does require some coding in the NODE and that is a challenge response system which allows for an external USB device

@dirvine

Then it will be a single password and a simple one. That is the empirical evidence so far. If we look at common password lists etc.

I’m sure there will be some mods done to change the entry requirements for credentials and if it is too difficult for the ordinary person then we have either the keeping the credentials written on paper OR the weakest credentials which is usually the easiest to remember and work with.

Incidentally if people keep to the minimum allowed because its too hard to remember more means the possibility of two people choosing the same credentials is higher since they will typically use words from a dictionary of less than 500 common words, may the 250/100 common word dictionary many use.

[jlpell]

The username + passphrase is so well burned onto the public mind that I think it is safe to say that two part credentials are a good thing, if only to later combine them for longer length as tfa is requesting.

Typically, humans have a really hard time keeping track of more than 4 pieces of information at the same time. So a single user or “portal” name of up to 4 words in length is the most we can expect from a human without resorting to pen and paper or other technology.

Imo, to complete the picture a passphrase should be provided to the user upon account creation to ensure security/safeness. Similar to how bip39 key generation works with seed extensions… (jump in here to correct me @mav) This way, minimum length and entropy can be enforced. The user would then need to store the passphrase offline (paper, hardware key) and encouraged to only store the username in their brain.

[drehb]

@jlpell

a passphrase should be provided to the user upon account creation to ensure security/safeness. Similar to how bip39 key generation works

The bip39 12 or 24 words thing is called a mnemonic.

I like the idea of generating the entropy for the user. You just then need to make sure that they’ve written down the backup that they need. This is the same approach taken by hardware wallets. For those unfamiliar, that process is as follows on initial boot up:

• choose if you want to restore an existing mnemonic, or create a new one
• if creating new one, device generates the random seed and prompts user to copy down mnemonic
• after words are written down, have user input them to verify they actually did what they were supposed to

It’s worth noting that in the case of hardware wallets, it’s a cardinal sin to enter this mnemonic data at a later time into an online computer. The whole point was to generate and keep this info safely offline. So that’s why it’s scary having “type this secret stuff in” as the main authentication workflow for SAFE.