-
Type:
Improvement
-
Resolution: Unresolved
-
Priority:
Unknown
-
None
-
Affects Version/s: None
-
Component/s: Authentication
-
None
This ticket was split from DRIVERS-2931, please see that ticket for a detailed description.
Background
Go now ships with a FIPS 140-3 certified "cryptographic module" (called the Go Cryptographic Module in documentation) that can be optionally linked at build time. We want to confirm that customers building applications with the Go Driver can run their application in "FIPS 140-3 mode" and reasonably expect to pass a FIPS 140-3 compliance audit when using SCRAM-SHA-256 auth.
Go 1.24 added some FIPS 140 settings via command line args:
- GOFIPS140= - Sets the version of the Go Cryptographic Module to link at build time
- GODEBUG=fips140= - Sets debugging modes for checking (but not certifying) FIPS 140 compliance.
For example, the following command runs tests, linking revision v1.0.0 of the Go Cryptographic Module (the only certified revision currently) and enabling "fips140=only" debug mode that errors/panics if any non-compliant cryptographic algorithms are used:
GOFIPS140=v1.0.0 GODEBUG=fips140=only go test ./...
Note that the "fips140=only" debug mode is best-effort and is not sufficient to certify an application or library:
If set to only, cryptographic algorithms that are not FIPS 140-3 compliant will return an error or panic. Note that this is a best effort mode meant for testing, assessment, and debugging. It is not intended to be used in production, it is not required by the Security Policy, it introduces crashes and potentially unhandled errors by design, and it may have false positives or false negatives.
For more details about FIPS 140-3 support in Go, see https://go.dev/doc/security/fips140
xdg-go modules
The Go Driver currently relies on two modules owned by xdg-go (David Golden) that are used during SCRAM-SHA-256 auth:
- github.com/xdg-go/scram
- github.com/xdg-go/pbkdf2
The "scram" module does not implement any cryptographic algorithms as covered by FIPS 140-3, but the "pbkdf2" module does. The "scram" module actually has different ways of calling the "pbkdf2" algorithm depending on Go version:
- https://github.com/xdg-go/scram/blob/v1.2.0/pbkdf2_go124.go - for Go 1.24 and greater; uses "crypto/pbkdf2" directly.
- https://github.com/xdg-go/scram/blob/v1.2.0/pbkdf2_legacy.go - for Go 1.23 and less; uses "github.com/xdg-go/pbkdf2"
The PBKDF2 algorithm is FIPS 140-3 compliant, but the "xdg-go" module is not certified (the built-in crypto/pbkdf2 package is). The Go Driver only officially supports Go 1.25+ as of the upcoming v2.9.0 release, so customers should technically be safe in an audit, but it definitely creates uncertainty and confusion that a non-certified PBKDF2 module is a Go Driver dependency. Ideally, we need to find a way to remove the dependency on "github.com/xdg-go/pbkdf2".
Definition of done
- Add a task that authenticates with SCRAM-SHA-256 and runs some authenticated commands (either with an existing test or a new test). Set the following environment variables:
GOFIPS140=v1.0.0 GODEBUG=fips140=only go test
- Remove the dependency, direct or indirect, on the "github.com/xdg-go/pbkdf2" module. There are different options for doing that:
1. Push a change to the "github.com/xdg-go/scram" repo that removes the "github.com/xdg-go/pbkdf2" dependency and sets the minimum Go version to 1.24 (the minimum Go version that includes the "crypto/pbkdf2" stdlib package).
2. Copy in the required code from "github.com/xdg-go/scram" module and remove both "xdg-go" dependencies.
3. Create a MongoDB-owned fork of "github.com/xdg-go/scram" and remove the "pbkdf2" dependency.- Ideally, we should try to do 1, then fall back to 2 or 3. Start by pinging David Golden on Slack and asking about adding better support for running in FIPS 140-3 mode by removing the "pbkdf2" dependency.
- depends on
-
GODRIVER-3882 Update to Go 1.26 in CI
-
- Closed
-