Possibly jumping the gun here but it seems like a login issue was solved by @bochaco who noticed the “normal” order of passphrase password was reversed in the latest GUI for SNApp
To help eliminate this confusion, I suggest the order of the two input is swapped but should we continue with naming these secrets, password and passphrase?
I know we had this discussion a few years back, possibly more than once but I can never say I was entirely happy with the naming of the two “secrets”.
Passphrase and password are just too similar for me. Internally I think of them as Password-1 and Password-2 and in every case I have them both of similar length and complexity. Its just two passwords to me - and almost every other user. Internally of course they do very different things, I think of one as a lock to a door “somewhere out there” and the other as my magic key that unlocks that far away door from the security of my device.
I solve this by using the same three letters for both
It’s something I wonder about on occasion but yet to come up with a better idea! Certainly Pass[insert suffix] is too much the same and confusing for being essentially the same… phrase perhaps is tempting that it’s a string of words but that is not encouraged by any tooling or requirement.
It’s almost tending to a something you are; something you have; etc but how to implement that in a useful way that affects the reality of needing two strands of text input, is not clear.
There is certainly something UI to be chewed over… if only for the related problem of users forgetting their account details. An option to spawn that input in other ways, perhaps will help - I’d like the idea of an ultra secure password/phrase that is memorable.
I’ve not spent time on this because, I keep falling towards wondering that it is a common problem for many other applications and surely there must be a good answer out there…
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.
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).
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.
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.
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)
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:
Invite claimed / account purchased etc.
User chooses password. pretty uncontroversial and understandable
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.
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.
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?
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.
