FIPS compliance should be used when the customer demands FIPS compliance, and at no other time. It does not make your software more secure. The federal government has many reasons for its Information Processing Standards, and actual security isn't high up the list.
That is backwards. NIST FIPS, especially FIPS 140, are explicitly security standards for cryptographic modules. They exist to define and validate security requirements and to give agencies a security metric for procurement. Security is central to the standard even if buyers also use it for compliance and contracting.
And when has FIPS certification made a product more secure than the non-certified version? By which I mean, give examples of actual cases in which hackers were stopped by the expensive FIPS-certified version but not by the equivalent non-certified one.
Absolutely. It allows you to check the box that says "must be FIPS certified", and that's it. Now I'm not saying that doesn't add value, but it's not adding any security.
> FIPS compliance is a great idea that makes the entire software supply chain safer
Yes, gotta implement that Dual_EC_DRBG compatibility.
FIPS compliance is not a great idea, the benefits are questionable and possibly nonexistent. It's also significantly worse advice than simple "implement decent modern crypto", you can do all kinds of really bizarre stuff and still be FIPS compliant.
>FIPS compliance is not a great idea, the benefits are questionable and possibly nonexistent.
I counter about the benefits of FIPS. If you don't do it, you don't get paid by the government for whatever contract you have. Many people find getting paid to be beneficial.
Now, it's not the vast majority of applications, but I'm sure there are a significant number of developers on HN that are working on applications that need to meet FedRamp requirements and posts like this point out potential pitfalls on what needs enabled.
Not much different when dealing with stuff like STIGs. A large number of them are highly questionable and may only apply to very specific applications, yet you see barely trained button pushers saying you need to follow them. If you're aware of them when writing your application it will save a bunch of implementation headaches when it ends up in the field.
Yeah, the first line was intended as a joke. I didn't communicate it very well though.
I think the problem with FIPS can be summed up very well as "it doesn't require you to implement good crypto", which makes it pointless and almost certainly harmful.
FIPS validates the crypto library, not your app design. It can still be a security upgrade for the crypto boundary, but you can build insecure stuff on top of it. The harm is when people treat “FIPS mode” as a magic security badge.
FIPS is what happens when idiots get promoted and start reading too much LinkedIn CISO slop.
If a customer demands FIPS compliance charge them out the ass for it. Its not inherently secure, it requires in some cases massive re-engineering of product and toolchains, and mostly seems to be an ask from clueless deep pocketed Fortune 500 companies looking to minimize liability claims after a breach by being able to point at their FIPS compliance.
FIPS is ancient and dates from the era when encryption was unusual and rare. That is why some of it seems so arcane. FIPS 140 didnt even allow software encryption until 140-3, 140-2 required a hardware secure enclave.
Definitely false, at least historically. The original FIPS only required HW at levels 3 and 4, "required" in the sense that levels 1 and 2 were quite doable in software (level was/is no authentication to the CM, letting it be protected by the host; level 2 was/is a form of basic authentication, e.g., encrypting private keys under a key derived from a password).
I was part of a team that had multiple level 1 and 2 certificates for software-only CMs in the 1990s, both 140 and the second edition, 140-1.
The current FIPS-approved OpenSSL module was released in 2023. FIPS compliance does not even allow security patches to address issues.
In my opinion, FIPS compliance is bad security practice and I suspect if a government agency called you on not meeting it, the justification of patching to address known vulnerabilities should hold up to scrutiny.
No, you can release another version but it needs to go through the testing and compliance regime which costs money and time.
This is the same as certifying an aircraft as airworthy. You can’t build another aircraft and say it is airworthy because the one you just built is airworthy too
Yes, gotta implement that Dual_EC_DRBG compatibility.
FIPS compliance is not a great idea, the benefits are questionable and possibly nonexistent. It's also significantly worse advice than simple "implement decent modern crypto", you can do all kinds of really bizarre stuff and still be FIPS compliant.
I counter about the benefits of FIPS. If you don't do it, you don't get paid by the government for whatever contract you have. Many people find getting paid to be beneficial.
Now, it's not the vast majority of applications, but I'm sure there are a significant number of developers on HN that are working on applications that need to meet FedRamp requirements and posts like this point out potential pitfalls on what needs enabled.
Not much different when dealing with stuff like STIGs. A large number of them are highly questionable and may only apply to very specific applications, yet you see barely trained button pushers saying you need to follow them. If you're aware of them when writing your application it will save a bunch of implementation headaches when it ends up in the field.
Not the entire RHEL STIG mind you but parts of it
I think the problem with FIPS can be summed up very well as "it doesn't require you to implement good crypto", which makes it pointless and almost certainly harmful.
If a customer demands FIPS compliance charge them out the ass for it. Its not inherently secure, it requires in some cases massive re-engineering of product and toolchains, and mostly seems to be an ask from clueless deep pocketed Fortune 500 companies looking to minimize liability claims after a breach by being able to point at their FIPS compliance.
I was part of a team that had multiple level 1 and 2 certificates for software-only CMs in the 1990s, both 140 and the second edition, 140-1.
In my opinion, FIPS compliance is bad security practice and I suspect if a government agency called you on not meeting it, the justification of patching to address known vulnerabilities should hold up to scrutiny.
This is the same as certifying an aircraft as airworthy. You can’t build another aircraft and say it is airworthy because the one you just built is airworthy too