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

Small Updates and Clarifications #6

Merged
sarah merged 13 commits from kngako-updates into trunk 2021-08-26 19:18:56 +00:00
Conversation 0 Commits 13 Files Changed 24 +3 -1
1 changed files with 3 additions and 1 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files
Showing only changes of commit 4e4b04c48d - Show all commits

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