You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The documentation should stress that cryptographically random keys must be used with the library. For example, advise users to run something like the following to create a new key:
In addition, strings passed by the user probably shouldn't be used directly as keys. Either advise users to pass real byte arrays of the right size, or run inputs through PBKDF2 to generate keys of the required size.
The text was updated successfully, but these errors were encountered:
@veeti thanks for the tip. I've just spent a half hour searching the net on how to best generate a key.
Now, I'm wondering how best to store them. Inside the koi.js documentation they just place those keys right inside the source code (which get's checked into source control).
Should I be importing them from an environment variable instead?
There is another node.js library called Iron that had a similar problem. More recently it started to enforce a minimum password length of 32 characters. However, it's still possible to overlook the need for a strong password and Iron-filings can be used to test for weak passwords.
As veeti also suggested, loading a base64 encoded random key from a configuration file would work well, that way it can be protected by the configuration management system (e.g. Puppet with Encrypted YAML files).
PBKDF2 is useful when trying to protect weaker user-selected passwords from brute-force attacks, but there is necessarily a performance penalty when using PBKDF2 with the recommended number of hashing iterations. Therefore, it's preferable to encourage or force the use of secure keys/passwords instead.
The documentation should stress that cryptographically random keys must be used with the library. For example, advise users to run something like the following to create a new key:
In addition, strings passed by the user probably shouldn't be used directly as keys. Either advise users to pass real byte arrays of the right size, or run inputs through PBKDF2 to generate keys of the required size.
The text was updated successfully, but these errors were encountered: