Password, passphrase

I much like the pass phrase and feel like it is a much clearer option than previous iterations. Account Secret seemed much more confusing than Passphrase to me. I just think it makes sense to put something memorable and unique to you as a passphrase.

passphrase: thatplaceifirstmetthatperson
password: Gy2h-h9TU-1mN5

Or we could just ask people for a “safe” word :joy:
Fun but not as secure.

2 Likes

If the problem is people forgetting which is which, maybe the system should just try swapping them if the first attempt fails.

I think there’s value in choosing terminology that encourages good choices, although there are other ways to do this (eg password/phrase strength checks).

1 Like

Just a question, why 2 passwords and not 1 very big one (and cut them in 2 if that’s needed for some reason).

I always ended up with 2 passwords that were the same on the test networks. Most people will probably do that I guess

6 Likes

That would tempt the sum is smaller and less secure.

Perhaps there needs to be a defined minimum cf auto generated 14 words.

1 Like

Why is Safenetwork not using the BIP39 standard: bips/bip-0039.mediawiki at master · bitcoin/bips · GitHub

Are there ideas to use hardware wallets for access to Safenetwork?

3 Likes

I agree about changing the naming. In the code it’s ‘locator’ and ‘password’. But not sure where to go with it!

https://github.com/maidsafe/safe_client_libs/blob/3e9d7f1f94990dce7c01ce8ab80aa8513bd66a1b/safe_authenticator/src/lib.rs#L112-L118

One acts as the encryption, the other acts as a locator. So you can change your password without losing your location (ie the root of your data structure) on the network. Even then, the password is not just that simple. Is it an id? Is it an encryptor? Is it this or that? It should probably be clearer.

I think both these terms would benefit from a change to reflect what they are and the consequences when choosing them. Password / passphrase / secret do not indicate ‘how do I choose this and what are the consequences’. One word to capture all this is not easy, but I feel the current words are misleading and hard to reason about. The normal ‘username + password’ is familiar but I feel is misleading.

I would normally advocate combining them for the sake of simplicity and using some sort of derivation scheme, but then we run into difficulties when users change passwords due to the way locator is designed.

This has been discussed a lot in the past, I couldn’t find exactly what I wanted but this is a pretty good starting point: password and secret explained.

10 Likes

Why not call it

  • Account passphrase
  • Account Password

Sorry for the sluggish reply guys, was off for a few days on homeschool duties.

I don’t favour this approach, and I’ll try and explain why.

The user needs to understand that both parts of the login are secret and private to them, and not to be shared with anyone, or publicly known. This is important because having any part of the login credentials shared or publically known now means that individual accounts can be targeted attack with a wordlist, bruteforce etc.

So labeling one part of it “Account Login” might infer that this acts like a traditional account credential set, with one part being a public value, like an email address or username, which is what most people are used to on the clearnet.

So if we are sticking to a two part system (notwithstanding some other 2FA, Yubikey, what-you-have additionals) we really need both labels to be unique, and confer the notion of secrecy and password-like usecase. Passphrase, and Password was the best attempt at this.

4 Likes

How about Account key / Network key?

Please create an Account key to protect your login (a password or passphrase 20+ characters long)
Please create a Network key to protect your data (a password or passphrase 20+ characters long)

2 Likes

That just makes it longer but still a source of confusion.

1 Like

Yes, and testing with user bore this out too. We didn’t just decide to change from Account Secret out of personal preference.

When we tested the process with the Secret label, it was a regular stumbling block. People would say things like:

“Do I need to give some secret information about me? What will happen to info I provide?”
“Am I supposed to already know the answer?”
“Where do I get this secret from? How do I get it one?”

It never went well.


We actually had in the plan to do some dedicated work on the account creation and login process to refine things further, and make things more understandable and secure, and I think this would really help the situation, and alleviate many of the concerns expressed in this thread. However, we could not justify the work on that for MVE, but I think we must return to it soon.

In short though, the first candidate idea which we did work up at some point (I can’t lay my hands on the design files right now… I’ll post them If I do) worked by walking users through things at onboarding time, roughly as follows:

  1. Invite claimed / account purchased etc.
  2. User chooses password. pretty uncontroversial and understandable
  3. Passphrase creation the user is provided a randomly generated passphrase (e.g. rash-clot-ball-glaze-avow-strife), in a format that aids the user in understanding its uniqueness, and a form that aids memorability. It would be pre-filled, and ready to save, but could be changed, overwritten, or edited, and also easy for the user to note down. It would also use slightly different UI elements, that would help in making it distinct from the password.

Taking it further for ease of use, perhaps:

  • The passphrase could be (optionally) cached locally on a trusted computer, so the user only needs the password for rapid login
  • The passphrase could be stored on hardware ala yubikey, or replaced entirely via some other 2FA element e.g. biometric.
  • When logging in the password and passphrase could be used interchangeably… perhaps there is a way that things will still work if the user puts the password in the passphrase field and vice-versa. I don’t know if this is achievable, but we did discuss it at one point.

So, I think we’ve got some good strategies to make this all work better down the line, and I think I’d still favour this method over a single long password, as I’d wager it will be more secure, and could also be more convenient with further refinement.

9 Likes

Interesting to get the reports of the user workshops.
Perhaps there is value in making it clear up front that SAFE is different from the traditional login/paraphrase format.

There are two secrets the hidden location of your gateway/door to SAFE and the key you use to open it.
Emphasize the dangers of brute-forcing but also emphasize the inherent security offered by having TWO secrets.

That’s what I was trying to get at with Account key / Network key. The challenge is to make it understandable at a glance.

1 Like

Discussion of 1 password vs 2 passwords here - seems most are in favour of one (although of course this doesn’t include login), for the reasons that a) 2 passwords are hard to memorise, b) people will get them mixed up c) people will just add a character to create the second password123 and password1234 d) it only marginally adds to security.

When 2 passwords are used it is generally in a 2-stage process, eg when you login to a bank account then need a pin to transfer funds.

For SAFE, could the second password be somehow securely generated from the first?

2 Likes

We could certainly do some derivation from a sufficiently lengthy string (or just split it up behind the scenes eg; there’s actually a third part ‘pin’ being derived behind the scenes at the moment, I think that’s a hangover from earlier account impl, but yeh, it can be done).

That would certainly give us more options. But I’d wholeheartedly cede to the test outcomes myself, though I am in favour of one long password as pretty much outlined in the link @JPL posted.

3 Likes

I like locator and password, as that is rooted in the reality of what they are.

1 Like

In these troubled times, let us find inspiration in large amounts of entropy

4 Likes

Hearing @mav’s points about reflecting meaning and @JimCollinson’s post about a more effective workflow (which I like), I wonder if we’re nearly there. At least for an MVP for market testing.

I think naming can make a big difference and have never liked ‘pashrase’, not just in this context but wherever I’ve heard it. I do wonder if it carries any meaning at all for most people.

So using Jim’s workflow and mav’s suggestion maybe ‘memorable account address’ or something which explains a little about it’s qualities and purpose. Combining this with automatically suggesting one to be used as in Jim’s example, seems useful.

I think ‘memorable account address’ is easier to remember and understand than passphrase. To begin, most people will accept what’s presented rather than edit and create their own, and a ‘Choose your own’ link can give advice for those who want that control.

When they get used to it people will shorten it to ‘account address’ and ultimately ‘address’ or ‘account’, but my belief is that they will retain the understanding that:

  • it needs to be long
  • it should be memorable
  • it identifies their account
2 Likes

I think this falls down at the must imply secret hurdle though. I can envisage phishing/social engineering attempts along the lines of “oh, what’s your account address by they way, so I can check we have you on our system?”.

I think naming can make a big difference and have never liked ‘passphrase’ … I do wonder if it carries any meaning at all for most people.

Don’t have oodles of data on this, but it compared much more favourably than Account Secret when we tested it, and no-one stumbled over it in any of the on-boarding/account creation tests we did.

This was the screen we used for that test, and the description provided:

Again, I think this could be much improved, though auto generation of a phrase-like entry, and UI elements that are more distinct from those used for the Password.

I think we can, and shall, do better than this, and we should dedicate some time to design and testing at some point.

Sadly lockdown make my usual user testing methods impossible! But I don’t think we need to rush into any changes ahead of MVE anyway, and hopefully the lockdown won’t be that longterm!

6 Likes

“Secret location address” and “password” ?

Emphasise a pass"word" can have many “words” and spaces in it.

Or Secret location address and passphrase if you really must, but not passphrase and password. Confusing and demeans the latter IMHO.