WalletConnect Password Login


#1

Here is a crazy idea to make WalletConnect session live longer. In order to protect localstorage session data from being scraped by malicious actors we could store them as password-encrypted keystore file, this would be light enough to use on browsers and provide a very similar user experience to Web2.0.

How would it look like?

First time you connect with WalletConnect would display a QR code, it would perform exactly the same as of now. Only after a successful connection, the user would be prompted to save the session with a password, allowing it to persist the session for as long as 30 days.

When returning to the Dapp the user would be prompted to type the password instead of the QR code and that session would be persisted without requiring the user to establish a connection all over again.

What if the user forgets his password?

The user would click “Forgot my password” and simply scan the QR code again to establish a connection for a new session.


#2

Interesting idea, probably secure enough. But I wonder if the benefit of saving the session outweighs the cost of introducing another moving piece for the user to get their head around. Is it too much friction to scan the QR code across browser sessions?


#3

That’s a good point but don’t forget Dapps already ask users to unlock their Metamask to “connect” hence it’s actually pretty normal right now. However maybe this should be optional and not as emphasized as much. Although that would be down to the Dapp to decide how to implement it.

My suggestion would be to make saving on localstorage optional but with the password requirement. The Dapp could even facilitate this by making it not user accessible.


#4

Is there any state associated with the connection other than the encryption key?


#5

Yes there is a counter (or nonce) for encrypting the payloads between the two devices


#6

Personally, I would scan again instead of putting password, but LastPass/1Password storing my password would be great in this case.

Small note: this will introduce more complexity at DApp level (in walletconnect.js) as now it has to maintain two state - encrypted (for long time) and decrypted session (for shorter time - in JS object).


#7

Yes but this would easily play along with the current draft for Session Management

What this thread specifically discusses is how this session data is stored. All the encryption that was put in place for transport would be exposed at rest hence this proposal