WebOfTrust
Provide support for passcode rotation
As a user of a Keria Cloud Wallet, I need to be able to rotate my passcode so that I can change the passcode if there is a risk that my passcode has been compromised.
Currently, there is no documented way to do this as far as I can see. There as been a discussion on the community discord a while back: https://discord.com/channels/1148629222647148624/1148734044545228831/1164288912500461729
There is a function in signify-ts (https://github.com/WebOfTrust/signify-ts/blob/development/src/keri/app/clienting.ts#L360) named rotate that accepts a new passcode. However, it triggers Internal Server Error in KERIA when called. Also a bit unclear what needs to be provided in the second parameter if the intention is to rotate a passcode.
In kli from keripy, we have the kli passcode set command that supports passcode rotation: https://github.com/WebOfTrust/keripy/blob/0c94c462a44c46f97a6c5d7e683fb9bf821154ba/src/keri/app/cli/commands/passcode/set.py
the feature was there initially, but probably is broken now. There were a couple of scripts in Signifypy that test passcode rotation and passcode rotation 1000 times. The thing with passcode rotation is that you need to regenerate and submit all new encrypted keys, that probably what should go in the second parameter.
From our keri dev meeting: Code is there but some integration testing and fixes are needed. Signify-ts has the call but KERIA gives a 500.
I have fixed this issue as part of a wave of SIGNIFY-TS testing and fixes related to multisig-vlei-issuance fixes that will include multisig delegation fixes as well https://github.com/WebOfTrust/keria/issues/249. We are approaching a new Keripy/KERIA release (per the dev discussion today)
Here are the current calls to rotate in siginfy-ts tests https://github.com/search?q=repo%3AWebOfTrust%2Fsignify-ts+rotate+path%3A%2F%5Eexamples%5C%2Fintegration-scripts%5C%2F%2F&type=code They are dominated by calls with only the aid and empty args (salty rotations).
@lenkan my sense is that we should refactor the integration tests so that multisig-vlei-issuance can act as a base test, and then other tests that depend on that data/scenario can 'build' on it piece-by-piece so that we can create a new tests to tackle things like multisig-rotation scenarios, all without adding duplicating the logic from multisig-vlei-issuance or adding to it. I had a similar need with the 'submit' command. One bit of testing I did was to add submit calls to the multisig-vlei-issuance test but not check it in, to avoid polluting that test with additional testing steps. Thoughts?
Here are the current calls to rotate in siginfy-ts tests https://github.com/search?q=repo%3AWebOfTrust%2Fsignify-ts+rotate+path%3A%2F%5Eexamples%5C%2Fintegration-scripts%5C%2F%2F&type=code They are dominated by calls with only the aid and empty args (salty rotations).
These are only rotating the keys used for the AIDs, the passcode in all scenarios are the same after rotation. But maybe that is what you meant with your last sentence?
@lenkan my sense is that we should refactor the integration tests so that multisig-vlei-issuance can act as a base test, and then other tests that depend on that data/scenario can 'build' on it piece-by-piece so that we can create a new tests to tackle things like multisig-rotation scenarios, all without adding duplicating the logic from multisig-vlei-issuance or adding to it. I had a similar need with the 'submit' command. One bit of testing I did was to add submit calls to the multisig-vlei-issuance test but not check it in, to avoid polluting that test with additional testing steps. Thoughts?
Yes, the tests do need some TLC. I had thought of something similar. These "base tests" can be referred to as test fixtures that can be broken out to functions that does the entire set up. Also, it would be nice to be able to restore the state of the fixture before each test is run to avoid having to do the setup for each test (although this might be considered premature optimization). I had some ideas on how to do that, but have not had the time to investigate.