Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Provide support for passcode rotation #222

Open
lenkan opened this issue Apr 4, 2024 · 5 comments
Open

Provide support for passcode rotation #222

lenkan opened this issue Apr 4, 2024 · 5 comments

Comments

@lenkan
Copy link
Collaborator

lenkan commented Apr 4, 2024

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

@rodolfomiranda
Copy link
Collaborator

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.

@2byrds
Copy link
Collaborator

2byrds commented Apr 25, 2024

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.

@2byrds
Copy link
Collaborator

2byrds commented Jun 13, 2024

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 #249.
We are approaching a new Keripy/KERIA release (per the dev discussion today)

@2byrds
Copy link
Collaborator

2byrds commented Aug 15, 2024

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?

@lenkan
Copy link
Collaborator Author

lenkan commented Aug 16, 2024

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.

@2byrds 2byrds added bug Something isn't working and removed bug Something isn't working labels Oct 17, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants