Session Lifetime & Management


#1

The current lifetime of the session for WalletConnect is 24 hours. This is currently only limited by the bridge implementation which discards the session after 24 hours. This needs to be handled on both browser and mobile side.

There are some concerns regarding how secure it is to persist the session data (session id, shared key and bridge url) on the browser local storage. Some suggestions included using iframes to sandbox this data but as mentioned by Taylor with her experience with MyCrypto, it’s not a secure approach.

Source of MyCrypto security audit: https://github.com/MyCryptoHQ/MyCrypto/wiki/Audit

There was also the suggestion for looking into U2F implementations used by Hardware wallets to learn how they secure their communications

For non-whitelisted origins, messages pass through an iframe trampoline, which must be loaded manually from the website, with the source chrome-extension://pfboblefjcgdjicmnffhdgionmgcdmne/u2f-comms.html. Since this iframe runs under a different origin, its scripts will not have access to the context of the containing web page. However, the web page can message it by creating a MessageChannel to obtain two entangled MessagePorts, and delivering one of them to the iframe via a postMessage with the body “init”.

As a short-term approach this session data could be simply stored on local storage for the time being for the Beta version of the WalletConnect standard


#2

This relates directly to the web browser repository: https://github.com/WalletConnect/walletconnect

More specifically this issue: https://github.com/WalletConnect/walletconnect/issues/4


#3

I created a diagram to visualize the logic flow when initiating a session

Initiating a session takes into account persisted sessions on local storage and verify the expiration time and also included a verification on the bridge server which for some reason might have removed this persisted session.

One of the assumptions that this diagram has is that the user accounts are also persisted, this is actually something that was dicussed previously but there hasn’t been any solutions to tackle this issue

Just like the session data, there needs to be some security and privacy considerations for persisting this data on the browser


#4

In order to display the accounts, the newly proposed approach was to persist it on the bridge server encrypted for as long as the session lives. This way not requiring it to be saved on local storage for persisted sessions. The idea is to allow for the session data to be sufficient for resuming persisted sessions


#5

Not sure if this belongs here but we should have a “remove push token for this session ID” functionality where the wallet can “disconnect” a dapp early by removing the session ID and associated push token for that session ID. This might be a good way to do it in case a Dapp goes rogue and abuses the push token it has access to during that time. But in general we should provide more control for a wallet to control its push token access on the bridge.


WalletConnect Password Login
#6

I agree, I think this definitely is relevant to this proposal and should be part of the specification