cwtch.im
/
secure-development-handbook
3
0
Fork 1
Code Issues 1 Pull Requests Releases Wiki Activity

Update 'src/profile_encryption_and_storage.md'

This commit is contained in:
kngako 2021-06-25 15:18:27 -07:00
parent bfc560e9d9
commit 4e4b04c48d
1 changed files with 3 additions and 1 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

4
src/profile_encryption_and_storage.md
View File

@ -1,6 +1,6 @@
# Profile Encryption & Storage
Profiles are stored on locally on disk and encrypted using a key derived from user-known password (via pbkdf2).
Profiles are stored locally on disk and encrypted using a key derived from user-known password (via pbkdf2).
Note that once encrypted and stored on disk, the only way to recover a profile is by rederiving the password - as such
it isn't possible to provide a full list of profiles a user might have access to until they enter a password.
@ -10,6 +10,8 @@ it isn't possible to provide a full list of profiles a user might have access to
To handle profiles that are "unencrypted" (i.e don't require a password to open) we currently create a profile
with a [defacto, hardcoded password](https://git.openprivacy.ca/cwtch.im/libcwtch-go/src/branch/trunk/constants/globals.go#L5).
<!-- Can cwtch be updated to randomly generate a password and store it on the devices keychain/keystore (for devices/OS with a keychain API)? Also I'm not sure how secure OS level keychains are but hard coded passwords always become campfire stories years later. -->
This isn't ideal, we would much rather wish to rely on OS-provided key material such that the profile is bound to a
specific device, but such features are currently patchwork - we also note by creating an unencrypted profile, people
who use Cwtch are explicitly opting into the risk that someone with access to the file system may be able to decrypt