I wouldn't say nothing. It is intended to ensure some level of security. And in some ways it can lead to decreased security if you comply with it (for example, if a vulnerability is found in your crypto library, you have to wait for the fix to be "validated" before you can patch it).
But yeah, complying with FIPS doesn't necessarily mean you are secure, and it is definitely possible to be secure without being FIPS compliant.
FIPS-140 doesn't even speak to most cryptographic vulnerabilities; it could prevent you from using, like, the PKZip cipher rather than AES, but not (really) from having code that could be induced into reusing a GCM nonce.
I may be thinking more about FedRAMP in general rather than just FIPS140-3, but mandating things like keeping user passwords out of logs is a security improvement.
And the average company needs to be dragged kicking and screaming to care about security at all.
> but mandating things like keeping user passwords out of logs is a security improvement.
That has nothing to do with FIPS 140.
FIPS 140 is just requirements for "cryptographic modules".
It specifies which algorithms are allowed and requires that you use modules that have been "validated" by going through an expensive and slow auditing process.
While I don't think it is completely useless to have those requirements, it has some problems, such as:
- it takes a very long time for anything to get validated. For example, Ubuntu 22.04 only recently got its crypto packages validated after being "in process" for years.
- bug fixes have to go through the validation process too, so if a vulnerability is found, you can be left vulnerable for a while
- For many languages and runtimes, using FIPS certified modules is a royal pain. For example, for several versions of node, there was no good way to run it in a FIPS compatible way, because it required a newer version of openssl than the latest FIPS certified version. AWS lambdas, even in GovCloud don't include FIPS certified crypto, so you have to bundle it in your package and make sure to use your local library instead of the system library, which can be quite difficult depending on the language. Prior to this change in go, using FIPS in go required using cgo to link to a FIPS certified c library, and make sure you either did some fancy link magic to get any libraries you used to also use that, or don't use any libraries that use the standard crypto library.
- It doesn't include many algorithms that are widely used and generally considered secure including Ed25519, chacha20-poly1305, argon (along scrypt, bcrypt, etc.), etc. This can cause problems with compatibility with other systems.
Luckily, FedRAMP have updated their FIPS guidance just this year to allow using crypto modules that have been validated and then received security patches. They realized that security patching is important and you don't need to recertify every patch before using it anymore.
This is about exclusively using "validated" implementations of specific cryptographic constructions. You can avoid it simply by not encrypting stuff at all, which is an indication of how little it has to do with security.
This has relatively little to do with actual security. It is compliance and certification theater for the most part. In many cases you can avoid it entirely by outsourcing caring about it to the customer. This isn’t always a bad thing; sometimes they understand and can deliver on their requirements much better than you can.
Doesn’t it at least keep snake oil crypto out of government? If it were removed it should be replaced by something. No standard would lead to a lot of crap being deployed.
The way you get quality products is by requiring and validating quality, not by picking a lowest common denominator and then pinning it in place for a decade with paperwork and calcified standards bodies.
But yeah, complying with FIPS doesn't necessarily mean you are secure, and it is definitely possible to be secure without being FIPS compliant.