Added option to encrypt files in database with pbkdf2 for key derivation and aes-256-gcm for encryption #6295
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
![github-advanced-security[bot]](https://avatars.githubusercontent.com/in/57789?s=60&v=4){kind=small}
| } | ||
| return key | ||
| default: | ||
| return parent.crypto.createHash('sha384').update(password).digest("raw").slice(0, 32); |
Check failure
Code scanning / CodeQL
Use of password hash with insufficient computational effort High
|
Just to get ahead of this: The CodeQL error here is on the old code that is still here for backward compatibility. That is the issue which this PR is trying to remedy. |
|
unfortunately @Ylianst wont accept this unless the codeql passed its test, so we need to fix this PR somehow |
|
Closed because the other version was merged. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This is the optional version of this that allows users to choose which version they want to use. For an opinionated and backward compatibility option, see: #6296
Currently, a simple sha384 hash is used for the key derivation for the encryption key of the key used to encrypt the files which are pushed to the database. This derivation method is fairly secure, however it may be weak to attacks in a theoretical post-quantum world. Changing this to a more computationally expensive algorithm can help with this. Meshcentral already uses pbkdf2 for password storage, so this is just enabling it for data encryption, though the current code for password storage is callback based and the code for encrypting and decrypting data is synchronous, so I did have to reimplement the pbkdf2 usage.
AES-CBC lacks any form of authentication and is therefor susceptible to modification attacks. Switching to AES-GCM solves this problem by adding an authTag.
The downsides of this approach are:
Concerns with this specific implementation, it is using the same IV for the encryption key and the kdf salt. Since the IV and salt are "public" anyway I believe this is fine, since the same key and IV/Salt will not be used for two different keys, but I'm not a security expert, so I could be wrong about that. If someone knows more and thinks it should be implemented differently, I can easily change it to use different random numbers.