Hey.. neat project!
From the docs at https://docs.doppler.com/docs/share-security :
> 2. Client-side JavaScript generates a cryptographically random 64 character passphrase
> 3. Client-side JavaScript generates a symmetric key using the passphrase, random salt, and 100,000 rounds of PBKDF2.
> ..
> 5. Client-side JavaScript create SHA256 hash of the passphrase
> 6. Client-side JavaScript sends the encrypted secret, hashed passphrase, and expiration details (days/views) to the server.
Using PBKDF (or any other "key-stretching" algorithm) is appropriate to prevent someone from cheaply building a table that maps from potential passphrase (+salt) to the potential symmetric key, ahead of time, and then quickly testing lots of potential keys against the encrypted data. If the passphrase is not full-strength to begin with, this is an important st
Read the rest
ep.
But.. if you then send a non-stretched, simple hash of the passphrase to the server, you're giving up all that benefit. The server, anyone who breaks into it, or someone who can snoop on the conversation, gets to perform the fast pre-computed dictionary attack against the passphrase. You've prevented the ciphertext from being used as a cheap oracle, but allowed the server's hashed-passphrase to serve that role instead.
The document didn't say what character set was used for each of the 64 characters of the passphrase, but even if it's just hex, that still gives you a 256-bit key, which is effectively infinite. So in this case, I don't think you need the PBKDF.
If the passphrase were not that strong, then I'd recommend protecting both values against being used as an oracle:
1: run the passphrase through PBKDF (or Argon2, or bcrypt, whatever) to produce the "stretched passphrase"
2: hash the stretched passphrase one way to produce the encryption key, e.g. key = sha256("key:" + stretchedPassphrase)
3: hash the stretched passphrase a different way to produce the hash that you reveal to the server, hash = sha256("hash:" + stretchedPassphrase)
4: never reveal stretchedPassphase to anyone else, or use it directly for any other purpose
That way a dictionary attack against any of the revealed values are equally difficult. This is effectively the scheme we used on Firefox Accounts to protect the Sync password: https://github.com/mozilla/fxa-auth-server/wiki/onepw-protoc... .
Also note: don't use different PBKDF round counts as a distinguisher, i.e. hash = PBKDF(rounds=10000, passphrase) and key = PBKDF(rounds=10001, passphrase). That amounts to the same thing, someone who learns the hash will get a cheap attack against the passphrase.
thanks for building this!