Update crypto library, CryptoJS CVE & deprecation

[cannikin]

So CryptoJS just dropped a bomb: everything they do by default is not as strong as it could be. Oh and by the way, the entire library is now deprecated. :( GHSA-xwcq-pm8m-c4vf Unfortunately we can't just upgrade to the latest release 4.2.0 because the hashing algorithm has changed, and a user would no longer be able to login: the default hash generated by CryptoJS 4.2.0 won't match the hash generated by CryptoJS 4.1.0.

Note that this is only an issue if someone got the contents of your database and wanted to figure out user passwords (but it still cost $45,000 per password apparently?).

In the wake of this CVE we're going to convert dbAuth to use the built-in node:crypto library instead, with more sensible default configuration.

There are two areas where we use the crypto libs:

1. Hashing the user's password to store in the DB and compare on login
2. Encrypting/decrypting the session data in a cookie

We're going to do this in a non-breaking way by supporting both the original CryptoJS-derived values, and the new node:crypto ones. The alternative would be to require every user to change their password, which seems like a non-starter.

1. On signup, store the hashedPassword using the new node:crypto algorithm
2. On login, compare the user's hashedPassword using the node:crypto algorithm:

• If a match is found, user is logged in
• If a match fails, fall back to the original CryptoJS algorithm (but using the node:crypto implementation)
  • If a match is found, update the hashedPassword in the database to the new algorithm, user is logged in
  • If a match is still not found, the user entered the wrong password.

Likewise for cookies and login:

1. When encrypting the user's session, always use the new node:crypto algorithm
2. When decrypting the user's session, first try with node:crypto

• If decrypting works, user is logged in
• If decrypting fails, try the older CryptoJS algorithm (I haven't figured how to use node:crypto to decrypt something that was encrypted with CryptoJS yet, so we'll need to keep the dependency on CryptoJS around for now)
  • If decrypting works, re-encrypt the cookie using the new node:crypto algorithm, user is logged in
  • If decrypting still fails, the session is invalid (someone tampered with the cookie) so log them out

Notifying Users

We could announce in the Release Notes that if a platform wants the absolute safest route, they should change their SESSION_SECRET and have users change their password if, for example, they suspect that their database may have been compromised before our release.

The next most secure thing would be to just change SESSION_SECRET which would log everyone out, and on next login their password will get re-hashed with the new algorithm.

But the default for most people will probably be to just go about business as usual, and as time goes by more and more users' passwords will be re-hashed on login.

Related to #9337 #9338 #9339 #9340

[cannikin]

This is the legacy decrypt function, we know it's insecure, that's why we're making this PR!

[cannikin]

This is the legacy decrypt function, we know it's insecure, that's why we're making this PR!

[Josh-Walker-GM]

Mentioned to @cannikin about the idea we should store the scrypt hash parameters with the hash into the database. This would allow us to change the default hash parameters should it be required to maintain security. Otherwise it would not be possible to know what set of parameters were used when we need to compare input to an existing hash.

This is something you can see with argon2 where the encoded hash typically looks like: $argon2id$v=19$m=16,t=2,p=1$QkFBSnRKdFlvSWRQUU1QWQ$MZKRYArC/s+ZqiPuPfIz+A. You can see how you can now test an input against this without the need to worry if your current default hash parameters match the ones used when this hash was created.

[cannikin]

A change to one of the same files I'm editing had a merge conflict from main (there was a getPort() function added to the end of the file). I fixed that, but also moved the function to the top of the file with the other non-exported functions, and changed it to an arrow function like the others. Let me know if there's a reason not to make either of those changes @jtoar

[jtoar]

@cannikin re the getPort, both changes are ok yeah

[jtoar]

@cannikin just pushed a commit (0e8e37d) that fixes linting issues:

• some TS in a JS file here

  redwood/packages/auth-providers/dbAuth/api/src/__tests__/DbAuthHandler.test.js

  Line 126 in 4755867

  (SESSION_SECRET as string).substring(0, 32),

• user wasn't used in this test:

  redwood/packages/auth-providers/dbAuth/api/src/__tests__/DbAuthHandler.test.js

  Line 1610 in 4755867

  const user = await createDbUser({ id: 7 })

[jtoar]

@cannikin we can remove crypto-js now right? looks like there's no imports from it but still listed in a few package.json files

[cannikin]

Oh yeah! I think I saw it in the lock and assumed it was a child dep of some other package, but maybe it was actually us!

[jtoar]

thanks @cannikin, let's get this in the patch RC