-
Notifications
You must be signed in to change notification settings - Fork 2.3k
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
Private wallet data preferences should be encrypted #2555
Comments
I think the best way to handle this is to add something like LedgerClient::EncryptString/LedgerClient::DecryptString which internally uses os_crypt. It doesn't look like there is "keychain" storage available on all platforms so I think we just need to encrypt before saving to disk (base64 encoded if saving to json). @diracdeltas ? |
what does os_crypt use to store the encryption key if a keychain-like mechanism isn't available? |
@diracdeltas os_crypt just encrypts the data using the OS encryption key and then we would just store the output in a file. I'm just saying that it doesn't look like we have a good way to directly store the output in something like macos keychain vs storing the encrypted output in a local file |
@bridiver i think we're on the same page here; in the original issue i mean store the encryption key in keyring (or whatever is available on the OS*), not store the private key itself in the keyring. the encrypted output can be stored in regular storage.
|
the only concern I have here is that 3rd-party clients may not properly encrypt the data and could make bat-native-ledger/ads look insecure through a poor implementation of the encrypt/decrypt methods. The alternative would be to embed os_crypt into the lib which should be ok because it has code for all platforms including IOS. cc @tmancey @SergeyZhukovsky |
Does this not encrypt on windows due to lack of an underlying OS keychain-like mechanism? |
we should also encrypt the Authorization token (stored in the Preferences file under |
@mrose17 - tracking |
Verified passed with
Verified plan 1 from brave/brave-core#6213. Confirmed able to connect to Uphold on clean profile and view balance. Confirmed able to 1 time tip. Confirmed able to perform AC and recurring tip. Verified plan 2 from brave/brave-core#6213. Confirmed brave://rewards was displayed correctly after upgrade from 1.15.x to 1.16.x and Uphold wallet was still connected as expected. After upgrade, confirmed able to 1 time tip. Confirmed able to perform AC and recurring tip. Verification passed on
Verified plan 1 from brave/brave-core#6213. Confirmed able to connect to Uphold on clean profile and view balance. Confirmed able to 1 time tip. Confirmed able to perform AC and recurring tip. Verified plan 2 from brave/brave-core#6213. Confirmed brave://rewards was displayed correctly after upgrade from 1.15.x to 1.16.x and Uphold wallet was still connected as expected. After upgrade, confirmed able to 1 time tip. Confirmed able to perform AC and recurring tip. Verification passed on
Verified plan 1 from brave/brave-core#6213. Confirmed able to connect to Uphold on clean profile and view balance. Confirmed able to 1 time tip. Confirmed able to perform AC and recurring tip. Verified plan 2 from brave/brave-core#6213. Confirmed brave://rewards was displayed correctly after upgrade from 1.15.x to 1.16.x and Uphold wallet was still connected as expected. After upgrade, confirmed able to 1 time tip. Confirmed able to perform AC and recurring tip. |
Verification passed on OnePlus 6T with Android 10 running 1.16.62 x64 build
Verification passed on Samsung Tab A with Android 10 running 1.16.62 x64 build
|
Description
Carried over from brave/browser-laptop#10705
The text was updated successfully, but these errors were encountered: