Merge pull request #13554 from vparpoil/feature/argon2-password-encryption

Feature argon2 password encryption

packages/accounts-base/accounts_common.js

@@ -218,9 +218,9 @@ export class AccountsCommon {
    * @param {Number} options.bcryptRounds Allows override of number of bcrypt rounds (aka work factor) used to store passwords. The default is 10.
    * @param {Boolean} options.argon2Enabled Enable argon2 algorithm usage in replacement for bcrypt. The default is `false`.
    * @param {'argon2id' | 'argon2i' | 'argon2d'} options.argon2Type Allows override of the argon2 algorithm type. The default is `argon2id`.
-   * @param {Number} options.argon2TimeCost Allows override of number of argon2 iterations (aka time cost) used to store passwords. The default is 3.
-   * @param {Number} options.argon2MemoryCost Allows override of the amount of memory (in KiB) used by the argon2 algorithm. The default is 65536 (64MB).
-   * @param {Number} options.argon2Parallelism Allows override of the number of threads used by the argon2 algorithm. The default is 4.
+   * @param {Number} options.argon2TimeCost Allows override of number of argon2 iterations (aka time cost) used to store passwords. The default is 2.
+   * @param {Number} options.argon2MemoryCost Allows override of the amount of memory (in KiB) used by the argon2 algorithm. The default is 19456 (19MB).
+   * @param {Number} options.argon2Parallelism Allows override of the number of threads used by the argon2 algorithm. The default is 1.
    * @param {MongoFieldSpecifier} options.defaultFieldSelector To exclude by default large custom fields from `Meteor.user()` and `Meteor.findUserBy...()` functions when called without a field selector, and all `onLogin`, `onLoginFailure` and `onLogout` callbacks.  Example: `Accounts.config({ defaultFieldSelector: { myBigArray: 0 }})`. Beware when using this. If, for instance, you do not include `email` when excluding the fields, you can have problems with functions like `forgotPassword` that will break because they won't have the required data available. It's recommend that you always keep the fields `_id`, `username`, and `email`.
    * @param {String|Mongo.Collection} options.collection A collection name or a Mongo.Collection object to hold the users.
    * @param {Number} options.loginTokenExpirationHours When using the package `accounts-2fa`, use this to set the amount of time a token sent is valid. As it's just a number, you can use, for example, 0.5 to make the token valid for just half hour. The default is 1 hour.

packages/accounts-password/password_server.js

@@ -34,9 +34,9 @@ const ARGON2_TYPES = {
 };
 
 Accounts._argon2Type = () => ARGON2_TYPES[Accounts._options.argon2Type] || argon2.argon2id;
-Accounts._argon2TimeCost = () => Accounts._options.argon2TimeCost || 3;
-Accounts._argon2MemoryCost = () => Accounts._options.argon2MemoryCost || 65536;
-Accounts._argon2Parallelism = () => Accounts._options.argon2Parallelism || 4;
+Accounts._argon2TimeCost = () => Accounts._options.argon2TimeCost || 2;
+Accounts._argon2MemoryCost = () => Accounts._options.argon2MemoryCost || 19456;
+Accounts._argon2Parallelism = () => Accounts._options.argon2Parallelism || 1;
 
 /**
  * Extracts the string to be encrypted using bcrypt or Argon2 from the given `password`.

v3-docs/docs/about/roadmap.md

@@ -4,7 +4,7 @@ Describes the high-level features and actions for the Meteor project in the near
 
 ## Introduction
 
-**Last updated: August 22nd, 2024.**
+**Last updated: March 6th, 2025.**
 
 The description of many items includes sentences and ideas from Meteor community members.
 
@@ -16,51 +16,39 @@ Contributors are encouraged to focus their efforts on work that aligns with the
 
 ### Next releases
 
-- Improve TypeScript support for Meteor and packages ([Discussion](https://github.com/meteor/meteor/discussions/12080))
-> Should be an ongoing effort to improve the TypeScript support in Meteor and packages, as we write new code in TypeScript and get more skin in the game, it should naturally improve. This doesn’t mean we will actively refactor working code.
+- Bundle optimization
+> We need to improve the bundle size and performance of Meteor apps. We should consider tree-shaking, code-splitting,
+> and other optimizations to make our apps leaner and faster.
+> To achieve that we plan to integrate or have an easy way to integrate with modern bundlers like RSPack, ESBuild, or Rollup.
 
-- Performance improvements for Meteor 3.0
-> After removing fibers, we became heavily reliant on async resources and consequently Async Hooks/Async Local Storage, which has a performance cost, we need to optimize that.
+- Support package.json exports fields ([Discussion](https://github.com/meteor/meteor/discussions/11727))
+- Tree-shaking
+> Tree-shaking and exports fields may be implemented by integrating with more modern build tools.
 
-- Bringing community packages to the core
-> Some packages are widely used and should be part of the core, which involves identifying and moving them to the core.
+- Capacitor support
+> Capacitor is a modern alternative to Cordova; we should provide an easy way to build mobile apps using Capacitor.
 
 - MongoDB Change Streams support ([Discussion](https://github.com/meteor/meteor/discussions/11842))
 > Change Streams is the official way to listen to changes in MongoDB. We should provide a way to use it seamlessly in Meteor. It has been planned for a long time, and now we’re in a position to do it.
 
-- Integrated support for Vite (Client Bundler, [Discussion](https://github.com/meteor/meteor/discussions/11587))
-> Vite is a fast and modern client bundler with an amazing ecosystem. It has many potential benefits for Meteor: build performance, tree-shaking, making our codebase leaner, and focusing on what we do best.
-
-- Replace Babel with ESBuild, Rollup, SWC, or another tool for the server bundle ([Discussion](https://github.com/meteor/meteor/discussions/11587))
-> Babel is a great tool, but it's slow and has some limitations; we should consider replacing it with a faster and more modern tool for the server bundle. We could potentially use the same tools Vite uses.
-
-- Support package.json exports fields ([Discussion](https://github.com/meteor/meteor/discussions/11727))
-- Tree-shaking
-
-> Tree sharking and exports fields may be implemented by integrating with more modern build tools, see previous items.
+- Improve TypeScript support for Meteor and packages ([Discussion](https://github.com/meteor/meteor/discussions/12080))
+> Should be an ongoing effort to improve the TypeScript support in Meteor and packages. We should provide a better experience for TypeScript users, including better type definitions and support for TypeScript features.
 
 - Improve release CI/CD speed and reliability (optimized build times will help)
-> Sometimes our CI/CD takes too long to run, causing long queues and delays in our release process and feedback loop, we need to improve that.
-
-- Improve support for Windows 11
-> We had many complaints in the past, we need to research and make architectural improvements to make it easier to support Windows, not just punctual fixes.
-
-- Document better Windows with WSL
-> It's already possible to use Meteor on Windows with WSL, but we need to document it better
-
-- HTTP/3 Support
-> HTTP/3 is the next version of the HTTP protocol. We should support it in Meteor to leverage its performance and security benefits.
+> Our CI/CD takes too long to run, causing long queues and delays in our release process and feedback loop; we need to improve that.
 
 ### Candidate items
 
 We need to discuss further to decide whether to proceed with these implementations.
 
+- Performance improvements (Async Hooks/Async Local Storage optimization)
+- HTTP/3 Support
 - Improve DDP Client
 - Improve Passwordless package ([Discussion](https://github.com/meteor/meteor/discussions/12075))
 - Integrate with Tauri, it might replace Cordova and Electron in a single tool
-- Support building mobile apps using CapacitorJS
 - Bring Redis-oplog to core ([Repository](https://github.com/Meteor-Community-Packages/redis-oplog))
 - Better file upload support via DDP ([Discussion](https://github.com/meteor/meteor/discussions/11523))
+- Improve usage in Windows environments
 
 ### Finished items
 

v3-docs/docs/api/accounts.md

@@ -817,24 +817,26 @@ Accounts.config({
 One enabled, the `accounts-password` package allows customization of Argon2's parameters. The configurable options include:
 
 - `type`: `argon2id` (provides a blend of resistance against GPU and side-channel attacks)
-- `timeCost` (default: 3) – This controls the computational cost of the hashing process, affecting both the security level and performance.
-- `memoryCost`: 65536 (64 MB) - The amount of memory used by the algorithm in KiB per thread
-- `parallelism`: 4 - The number of threads used by the algorithm
+- `timeCost` (default: 2) – This controls the computational cost of the hashing process, affecting both the security level and performance.
+- `memoryCost`: 19456 (19 MiB) - The amount of memory used by the algorithm in KiB per thread
+- `parallelism`: 1 - The number of threads used by the algorithm
 
 To update the values, use the following configuration:
 ```js
 Accounts.config({
     argon2Enabled: true,
     argon2Type: "argon2id",
-    argon2TimeCost: 4,
-    argon2MemoryCost: 65536,
-    argon2Parallelism: 4,
+    argon2TimeCost: 2,
+    argon2MemoryCost: 19456,
+    argon2Parallelism: 1,
 });
 ```
 
 Other Argon2 parameters, such as `hashLength`, are kept to default values:
 - `hashLength`: 32 bytes - The length of the hash output in bytes
 
+The default values are the minimum [OWASP recommendations for Argon2 parameters](https://cheatsheetseries.owasp.org/cheatsheets/Password_Storage_Cheat_Sheet.html#introduction). When updating these values, consider the trade-offs between security and performance on the target infrastructure.
+
 For more information about Argon2's parameters, refer to the [argon2 options documentation](https://github.com/ranisalt/node-argon2/wiki/Options).