Closed simo5 closed 2 weeks ago
Note, this commit also drops the special use code available only in tests that was disabling encryption as it turns out that now that we do not decrypt every object on search but only on explicit fetch the test are not that slow anymore.
Or rather the slow tests are gated behind the "slow" feature, so it is not a big deal if thy are really slow.
Let me know if you think this is too slow:
$ cargo test --features slow
[..]
test result: ok. 176 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 258.00s
I think it is fine given:
$ cargo test
[..]
test result: ok. 176 passed; 0 failed; 0 ignored; 0 measured; 0 filtered out; finished in 5.19s
Thank you!
This splits out the storage spefcific knowledge from the token to the actual storage backend.
The storage backend is restructured so that multiple storage types can use a common information organizational schema for non standardized objects like user pins and token info and non standardized authenticationand encryption layers for the actual data.
This is in preparation for adding code to read databases written by other software tokens that follow different storage philosophies.
While woring on this refactoring a few minor issues with how pin/login were handled was found and have been fixed.
Additionally the code now uses a common Key encryption Key that both the Ueer and SO Pins can unlock allowing recovery of the database via SO pin if the user pin is lost. This means the SO pin needs to be set to a non-default value on initialization to maintain the confidentaility of the token. It can be set to a random value if recovery is never desired.