search

LDLN / core

Wiki documentation, core models, and utilities shared by various LDLN packages.
GNU General Public License v3.0
1 stars 0 forks source link

Salt for password concantentation should be extracted to a config file #2

Open mr-z-ro opened 8 years ago

mr-z-ro commented 8 years ago

https://github.com/LDLN/core/blob/master/cryptoWrapper/main.go#L35

First, a salt should not be hard-coded, especially in an open-source project. Second, we'll want to make this configurable on a deployment-by-deployment basis.

nickihm commented 8 years ago

Yep, yep. I think I mentioned this in the slack channel a while ago, but there is no point in hard-coded, open-source salt. When it comes to password hashing though, I think we should look at using some key-stretching algorithms like PBKDF2 or bcrypt. RNcrypt supports PBKDF2 as part of its library.

mr-z-ro commented 8 years ago

Yeah I remember you bringing it up as well in slack, along with a few other things. As you've even said in the past though, I think it's best to continue the initiative of "eating our own dog food." In this case, acting as true contributors to our own codebase and tracking issues in an open way (out of our emails and im convos). That way perhaps (although not extremely likely at this point) another dev may stumble across and submit a pull request. Anyway, let me know if you disagree and I'll hold off.

Other than that though, totally agree about the key-stretching though for the hashing for auth. I'll make a separate issue for that.

I think we should keep the scope of this particular issue to the salt that's concatenated to form the KEK that decrypts the DEK (using the functional names of these keys here and not the variable names).