You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository was archived by the owner on Dec 13, 2021. It is now read-only.
Currently a session is persisted in localStorage in browser environments which allows a Dapp to maintain the connection to make call requests. Disregarding the security concerns of the exposure of the symmetric key which are described in the WCIP-2, there are also other security concerns regarding the user maintaining a session indefinitely open on a device that it may or may not own.
Considering the scenario where you establish a WalletConnect session with a Dapp and is persisted. An attacker could access the device which persists the session by simply opening the same Dapp where this session is persisted. Although this attacker could not sign anything without the possession of the user's Wallet, it could still access all read information displayed by the Dapp.
This could be seen as failure of the Dapp to re-authenticate by requiring a time sensitive signature by the user's Wallet. We could ever mitigate by implementing ourselves on the WalletConnect side.
Hence we would add an expiry date to all persisted sessions. I propose a 24 hour timeframe for this expiry. Whenever this expiry date is reached, the user will be required to sign a personal_sign or eth_signTypedData message that re-authenticates the session for another 24 hours. Otherwise the session will be disconnected after 5 minutes have passed since its expiry date.
Currently a session is persisted in localStorage in browser environments which allows a Dapp to maintain the connection to make call requests. Disregarding the security concerns of the exposure of the symmetric key which are described in the WCIP-2, there are also other security concerns regarding the user maintaining a session indefinitely open on a device that it may or may not own.
Considering the scenario where you establish a WalletConnect session with a Dapp and is persisted. An attacker could access the device which persists the session by simply opening the same Dapp where this session is persisted. Although this attacker could not sign anything without the possession of the user's Wallet, it could still access all read information displayed by the Dapp.
This could be seen as failure of the Dapp to re-authenticate by requiring a time sensitive signature by the user's Wallet. We could ever mitigate by implementing ourselves on the WalletConnect side.
Hence we would add an expiry date to all persisted sessions. I propose a 24 hour timeframe for this expiry. Whenever this expiry date is reached, the user will be required to sign a
personal_signoreth_signTypedDatamessage that re-authenticates the session for another 24 hours. Otherwise the session will be disconnected after 5 minutes have passed since its expiry date.