In response to another post I was asked to create a thread that would outline what would be required for FIPS compliance such that ContentBox would be more attractive to government entities.
There are a lot of things that go into securing a site for use by a government entity, but one simple enhancement would be to enable developers to specify any of the built-in hashing algorithms for use with logins. This is not a panacea as not all algorithms are available on all CF installations due to: a) the version of CF installed, and b) whether or not the FIPS compliant algorithms have been excluded from the CF installation due to US export controls.
Being able to specify hashing algorithm, salt, iterations, etc. for passwords would be an ideal first step - providing control of all parameters of the hard coded hashing.
I would also recommend the same for encryption (encryptIt function): ability to specify algorithm, salt, etc.
We actually have a ticket in place to employ Bcrypt hashing for storing author passwords. Would that satisfy the password portion?
Regarding encryption, is this for the actual contents of each page/entry? Would ContentBox needs to allow for the admin to choose things like algorithm to be FIPS compliant, or would that just be more for convenience?
I would give developers the ability to specify the algorithm instead of hard coding it. This would enable forward compatibility so developers can move to newer FIPS compliant algorithms as they are specified by NIST.
Additionally, providing the ability to specify the other aspects of hashing enables better security, which some organizations may require the use of.
To clarify, Bcrypt (or JBcrypt in our case) is not an algorithm, it’s a library that uses the BlowFish block cipher with iterations and salt. I’m actually surprised to see that BlowFish doesn’t appear to be an approved FIPS algorithm, as Bcrypt is generally touted to be an industry standard.
No, I do not want to encrypt all content. Enabling encryption of page content would, indeed, be another step, but not the scope of this issue. For CB’s built-in hashing and encrypting, if you want to make it more attractive to government users, provide developers the ability to specify the specifics of hashing and encrypting/decrypting.
Do a search on FIPS compliant algorithms and you’ll find the few that are actually acceptable (both hashing and encrypting algorithms). Providing developers the opportunity to specify their algorithms and other parameters of the base cfhash and cfencrypt/cfdecrypt functions lets anyone use whatever they want. In the case of government, it’s necessary to comply with FIPS.
Something like this shouldn’t be core, I agree that something as a base to extend would be a good move. This sort of thing screams modules and AOP, or even Interception points. The latter being the preferred as you can flag which can or can’t be encrypted to met what ever requirements and/or have multiple encryption points depending on if there is two ways to do it.
Doesn’t really matter to me. I was just asked to post on the topic. I have already created my own functionality that overrides the built-in encryption and hashing.
Sorry it was more of a general out there statement. I am sure places where this maybe required may get their own interception points, making it easier to plug in the functionality rather than writing umpteen different interceptions points, when one or two may work.
Thanks for the feedback. I really want to be able to improve our core as we have had many internal discussions on this.
I have more questions for you, since it seems you have already a solution.
Would you be willing to share your solution?
What FIPS compliant algorithm would you suggest we use for hashing and encryption that could be a base. I get the customizations portions. However, as a global base, what would be your recommendation?
Contractual obligations preclude me from sharing my code. I will note, however, that in my instance I did not use a purely CF solution as it’s implementation of the FIPS compliant hasing algorithm yields different results from other languages, thus preventing hash matching by those other languages. I would assume you would not want to go that route with the ContentBox core.
As for which algorithm, I would keep your current as the default, but allow developers to select from those listed for the hash and encrypt functions.
As a follow-up, I would recommend updating the core to automatically encrypt any PII stored in the system out of the box. You can use the Wikipedia page on PII for a quick guide.
