feat: secure information handling

weboko commented 12 months ago

This is a **feature request** ## Problem There is always a risk of `XSS` happening and someone taking away the credentials of a user. It becomes more critical in the scope of RLN when credentials might be stored on `js-waku` side. ## Proposed Solutions This is more exploratory work where we should look into: - [ ] since `waku` messages are plain we can look into providing utility to guard against `XSS`; - [ ] explore `passkey` API in browsers if is it possible to use it for safer storage of creds; - [ ] create an entity in our code (package or class) to handle safer / persistent storage of some information (creds etc); note: `passkey` might not be a storage per se but a source of information for following credentials generation etc. This might not be needed right now but could be a good building block for the future. It is worth exploring already implemented solutions out there and maybe re-using them. One potential solutions are researched we should follow up with research if necessary. ## Notes Useful links: [passkey](https://web.dev/passkey-registration/), [MetaMask](https://community.metamask.io/t/security-of-secret-recovery-phrase-private-keys/24607/2)

weboko commented 6 months ago

Problem

Right now @waku/rln has two points of contact with RLN identity.

Registering

As it is written here in order to register RLN identity with @waku/rln consumer should:

sign a message by using wallet;
using signed message as a seed - generate an identity;
use this identity to register on RLN contract;
save it as Keystore for later use;

Seeing this it is clear that dependency on the wallet exists only because of a need to create a seed by signing a message.

Using identity

Once RLN identity is saved in the Keystore format it can be passed to @waku/rln like done here to be used by the library for proof generation like setup here and usage here.

But there are couple problems:

Keystore format should be decrypted so that password should come with it, here;
Keystore should be stored somewhere and after decryption should not be leaked;

This makes it poor to be re-used in a web app at the very least.

Solution

Let's use passkey. It is a pair of public/private keys that securely stored on a device and can be shared with others and more importantly - comes with great UI on various platforms - browsers / iOS / Android. We can use it for addressing problem with RLN identity generation and following usage of it.

Registering

With passkey we would eliminate dependency on wallet and can generate a seed directly with it by either signing some message or doing something else:

const signature = [passkey].sign(same message);
const identity = this.zerokit.generateIdentityCredentials(signature);
// registration

Using identity

Here comes a nice bonus of not having to store any Keystore and we can reliably re-generate RLN identity again by using passkey from the device.

Limitations

Main limitation is passkey are domain or application specific meaning they won't be re-used so if user has a RLN identity at a website - it won't be possible directly re-use it so new identity would be needed to be created.

Potential mitigations:

once user wants to re-use identity - it can be exported in a Keystore format but later usage would be more complicated;
maybe there is a way to duplicate passkey across different domains - doesn't seem secure;

Next steps

We can try to make a PoC to and have an example app in lab.waku.org to showcase it.

In order to bring it to production we need to understand:

(if no mitigation) how problematic is to have user creating identity for each Waku powered app they use;
if there is any request for it to become part of the library, since it is possible for consumers to build on top;

danisharora099 commented 5 months ago

passkeys look pretty cool! a POC would be fun

on a side note: since they are quite new, how do you think about the education + onboarding part should be handled by us?

waku-org / js-waku