4 ms·
I read the whitepaper, and while I have many questions one detail in particular jumped out at me: "The client authenticates with an X.509 certificate or a self
by swordswinger12 11y ago
I read the whitepaper, and while I have many questions one detail in particular jumped out at me:
"The client authenticates with an X.509 certificate or a self-signed certificate
where the private key is derived from a passphrase. When a passphrase is used, the scrypt algorithm is used to derive
a private key from the passphrase. Information about the salt is stored server-side and is given before establishing an
authenticated encrypted connection.
... The symmetric key is derived from either the passphrase,
the private key in an X.509 certificate, or provided by a key management service (KMS)."
You're deriving a private key from a user-defined passphrase, then storing the salt used to derive the password on the server, which is defined to be untrusted. I understand you use scrypt to derive the private key, but this still seems like a massive, massive footgun. Database systems are usually kept up and running for a long time, like maybe even years. If the server gets the salt, isn't it only a matter of time before even a very slow brute-force attack can re-derive the authentication credential and make whatever queries it wants?
- michwill 11y agoDeriving from passphrase is optional. Mainly, for development and testing, and also for users who are ok with passphrases. Having a passphrase + server-saved salt makes it better than a passphrase with no salt (for brute-force by dictionary). If you think about it, security of passphrase approach is tested all the time with Bitcoin brain wallets. Over there, private keys are derived using SHA256 (which is fast to compute!) with no salt. It's hard for humans to generate good passphrases, so these wallets do that for them (usually 12 words). But yeah, in most production usecases it would be some certificate, or KMS
- swordswinger12 11y agoYeah, this approach has been tested and has failed miserably: http://eprint.iacr.org/2016/103.pdf http://eprint.iacr.org/2016/103.pdf