We’re doing a bit of research on alternative onboarding strategies. Local password vs. seed phrase (Secret Key) tends to confuse many new users. We’ve been looking at crypto wallets that do a good job of sharing seeds and putting up fast, but effective, verification methods—which, in theory, would let us ditch email/password in the browser.
If our goal is to remove any “password” besides the seed, we might consider:
Remove any and all password functionality in the browser
Or, use the seed itself as a local encryptor. So still have local password in a sense, but for user they only need to worry about a single piece of information for ID security.
I’m curious about the potential downsides of either option. Could be UX, security, or other…
Just did a quick inventory of the obvious places password is used now:
I don’t think you’d want the user to re-enter the seed phrase every time they want to make a wallet transaction… thus you’d have to store the private key within memory/localstorage if you wanted to get rid of the password. I don’t know how safe this is, but it may be fine.
What other verification methods are there that are faster then typing in a cheap passphrase?
On another note, you could push the seed phrase into gaia while being encrypted with the password so you could recover with only username (not email) & password, but then you would allow hackers to do dictionary attacks against it for “free.”
(Local) password might be the wrong word, better maybe PIN or Unlock Word. Users have to get taught that they are doing new things here.
I like to not carry my seed phrases with me all the time and still be able to USE wallets. RESTORING the wallet is a different story. I would like to keep my keys on a hardware wallet.
I think having the enter the seed phrase again even for less frequent actions would compel some users to write their seed phrase on a sticky note or save it in a text file on their computer. That would be really unsafe.
In the future, when smart contracts are available on the Stacks blockchain, transactions could become a frequent action. In which case it would be really annoying and unsafe to have to enter your seed phrase every time.
The problem with PIN is that is you need many digits for the encryption to be secure enough.
@friedger 's post is spot on! The word password is just wrong. Users from traditional apps assume that it is the same type of password they enter for a traditional app. It isn’t. We are confusing them by trying to leverage old words in new context.
Just as using the password word signals to a user they can rely on previous situational knowledge, using a unique word signals the opposite.
latchkey
sessionkey
countersign
counterkey
And, we have an opportunity to establish a new paradigm. We have left the world of username/password. Our onboarding design is still clinging to it.
I agree that maybe we need a different name, but irrespective of the name, we still need to form an informed opinion on these security and UX concerns Ken mentioned. That is really the heart of the question IMO.
If we completely remove, the name problem is solved. If we decide we cannot remove, then we should dive deep into what name is right.
Been thinking about this a bit more. A proposal might look like this:
Remove feature
View/access stored seed
Remove password from these features:
Upgrade the browser
Reset the browser
Altered approach to password:
Creating new IDs
BTC transactions / STX transactions
.ID name transactions
We do not store the seed in browser at all. When users want to perform these actions, we prompt them to re-enter the seed. When they do this the 2nd or 3rd time, we also provide an option to create a “Secret Key Shortcut” or some other term that is the same functionality we currently have.
Essentially we only provide this shortcut to users who demonstrate they need it by creating many IDs or many transactions. So advanced users get fast/easy transactions and new users have no idea password is a thing.
