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.