FPV-662: fix(authorization): replace weak PRNG with CSPRNG for PKCE code_verifier generation - #5153
FPV-662: fix(authorization): replace weak PRNG with CSPRNG for PKCE code_verifier generation#5153Kesari3008 wants to merge 4 commits into
Conversation
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: eac820f794
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| const safeCharacterMap = base64url._safe_map; | ||
| const randomValues = new Uint8Array(128); | ||
|
|
||
| this.webex.getWindow().crypto.getRandomValues(randomValues); |
There was a problem hiding this comment.
Support the prefixed CSPRNG in IE 11
When this package runs in IE 11—which is explicitly included by the root Babel target ie >= 11—the Web Crypto implementation is exposed as window.msCrypto, not window.crypto; this dereference is therefore undefined and every initiateLogin() call aborts before navigation. Select the available crypto or msCrypto implementation so PKCE generation remains usable in this configured browser target.
Useful? React with 👍 / 👎.
rarajes2
left a comment
There was a problem hiding this comment.
LGTM. Please see if you can run the script/skill which caught this issue and it accepts this change.
Checked with Kesava, there is a separate team who does this and we can rescan the PR fix |
COMPLETES #https://jira-eng-gpk2.cisco.com/jira/browse/FPV-662
This pull request addresses
Security fix: The
_generateCodeChallengemethod inauthorization.jsusedlodash.random()(backed byMath.random/ xorshift128+), a non-cryptographic PRNG, to generate the 128-character PKCEcode_verifier. This violates RFC 7636 §7.1 and SEC-CRY-RANDOM-4 which require a cryptographically secure random source. Predictablecode_verifiervalues expose the OAuth PKCE flow to offline brute-force attacks.Root Cause:
lodash.random()usesMath.randominternally, which is a non-cryptographic PRNG.by making the following changes
lodash.random()loop in_generateCodeChallengewithwindow.crypto.getRandomValuesusing a bias-freebyte & 63masking approach over the 64-character base64url alphabetrequirefrom_generateCodeChallenge(no new dependencies needed;window.cryptois already accessible viathis.webex.getWindow().crypto)window.crypto.getRandomValuesis called,Math.random/lodash.randomare never called, the verifier is 128 chars of base64url-safe characters, and the S256 challenge is the SHA-256/base64url hash of the verifierChange Type
The following scenarios were tested
_generateCodeChallengecovering:window.crypto.getRandomValuesis called (AC-6)Math.random/lodash.randomare never calledAcceptance Criteria
window.crypto.getRandomValuesused in_generateCodeChallengereplacinglodash.random()byte & 63masking over 64-char alphabet eliminates modulo bias; length fixed at 128getRandomValuescalled andMath.random/lodash.randomnever calledThe GAI Coding Policy And Copyright Annotation Best Practices
I certified that
Make sure to have followed the contributing guidelines before submitting.