Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Guide users to generate secure keys & add proper key derivation #26

Open
veeti opened this issue Feb 13, 2016 · 3 comments
Open

Guide users to generate secure keys & add proper key derivation #26

veeti opened this issue Feb 13, 2016 · 3 comments

Comments

@veeti
Copy link

veeti commented Feb 13, 2016

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:

node -e "console.log(require('crypto').randomBytes(32).toString('base64'))"

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.

@criticalmash
Copy link

@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?

@veeti
Copy link
Author

veeti commented Feb 21, 2016

An environment variable or configuration file would be my choice.

@tkeetch
Copy link

tkeetch commented Apr 22, 2016

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants