spaceman

5.0/en/0x11-V2-Authentication.md

@@ -52,7 +52,7 @@ The requirements in this section mostly relate to section [5.1.1.2](https://page
 | **2.1.7** | [MODIFIED, SPLIT TO 2.1.13] Verify that passwords submitted during account registration or password change are checked against an available set of, at least, the top 3000 passwords. | ✓ | ✓ | ✓ | 521 |
 | **2.1.8** | [DELETED, INSUFFICIENT IMPACT] | | | | |
 | **2.1.9** | Verify that there are no password composition rules limiting the type of characters permitted. There should be no requirement for upper or lower case or numbers or special characters. | ✓ | ✓ | ✓ | 521 |
-| **2.1.10** | [MODIFIED, LEVEL L1 > L2] Verify that a user's password stays valid until it is discovered to be compromised or the user rotates it. The application must not require periodic credential rotation. | | ✓ | ✓ |  |
+| **2.1.10** | [MODIFIED, LEVEL L1 > L2] Verify that a user's password stays valid until it is discovered to be compromised or the user rotates it. The application must not require periodic credential rotation. | | ✓ | ✓ | |
 | **2.1.11** | Verify that "paste" functionality, browser password helpers, and external password managers are permitted. | ✓ | ✓ | ✓ | 521 |
 | **2.1.12** | [MODIFIED] Verify that password input fields use type=password to mask the entry. Applications may allow the user to temporarily view the entire masked password, or the last typed character of the password. | ✓ | ✓ | ✓ | 549 |
 | **2.1.13** | [ADDED, SPLIT FROM 2.1.7, LEVEL L1 > L3] Verify that passwords submitted during account registration or password changes are checked against a set of breached passwords. | | | ✓ | |
@@ -82,7 +82,7 @@ The requirements in this section relate to a variety of sections of [NIST's Guid
 | **2.2.5** | [MOVED TO 9.3.3] | | | | |
 | **2.2.6** | [DELETED, DUPLICATE OF 2.7.3, 2.8.4] | | | | |
 | **2.2.7** | [DELETED, MERGED TO 2.2.4] | | | | |
-| **2.2.8** | [ADDED] Verify that valid users cannot be deduced from failed authentication challenges, such as by basing on error messages, HTTP response codes, or different response times. Registration and forgot password functionality should also have this protection. | | | ✓ |  |
+| **2.2.8** | [ADDED] Verify that valid users cannot be deduced from failed authentication challenges, such as by basing on error messages, HTTP response codes, or different response times. Registration and forgot password functionality should also have this protection. | | | ✓ | |
 | **2.2.9** | [ADDED, SPLIT FROM 2.2.4] Verify that the application requires users to either use a multi-factor authentication mechanism or a requires a combination of single-factor authentication mechanisms. | | ✓ | ✓ | 308 |
 | **2.2.10** | [ADDED, SPLIT FROM 2.2.3] Verify that users are notified of suspicious authentication attempts. This may include successful or unsuccessful authentication from an unusual location or client, partially successful authentication with only one of multiple factors, successful or unsuccessful authentication after a long period of inactivity or successful authentication after several unsuccessful attempts. | | ✓ | ✓ | 778 |
 | **2.2.11** | [ADDED, SPLIT FROM 1.2.4] Verify that, if the application includes multiple authentication pathways, there are no undocumented pathways and that security controls and authentication strength are enforced consistently. | | ✓ | ✓ | 306 |
@@ -115,7 +115,7 @@ In particular, note that since these algorithms are intentionally compute-intens
 | **2.4.3** | [DELETED, MERGED TO 6.6.2] | | | | |
 | **2.4.4** | [DELETED, MERGED TO 6.6.2] | | | | |
 | **2.4.5** | [DELETED, INCORRECT] | | | | |
-| **2.4.6** | [ADDED, SPLIT FROM 2.1.2] Verify that the application is protected against a denial of service attack caused by processing an overly long password. | | ✓ | ✓ |  |
+| **2.4.6** | [ADDED, SPLIT FROM 2.1.2] Verify that the application is protected against a denial of service attack caused by processing an overly long password. | | ✓ | ✓ | |
 
 ## V2.5 Credential Recovery
 
@@ -167,7 +167,7 @@ The requirements in this section mostly relate to section [5.1.3](https://pages.
 | **2.7.5** | [DELETED, INSUFFICIENT IMPACT] | | | | |
 | **2.7.6** | [MODIFIED] Verify that codes used in out-of-band authentication are generated using a cryptographically secure random number generator (CSPRNG) and contain at least 20 bits of entropy (typically 4 random alphanumeric characters or 6 random digits is sufficient). | | ✓ | ✓ | 310 |
 | **2.7.7** | [ADDED] Verify that a code based out-of-band authentication mechanism is protected against brute force attacks by using either rate limiting or a code with at least 64 bits of entropy. | | ✓ | ✓ | 307 |
-| **2.7.8** | [ADDED] Verify that, where push notifications are used for multi-factor authentication, rate limiting or number matching is used to prevent push bombing attacks. | | | ✓ |  |
+| **2.7.8** | [ADDED] Verify that, where push notifications are used for multi-factor authentication, rate limiting or number matching is used to prevent push bombing attacks. | | | ✓ | |
 
 ## V2.8 Time based One-time Passwords
 

5.0/en/0x14-V6-Cryptography.md

@@ -49,9 +49,9 @@ Although this section is not easily penetration tested, developers should consid
 | **6.2.2** | Verify that industry proven or government approved cryptographic algorithms, modes, and libraries are used, instead of custom coded cryptography. | | ✓ | ✓ | 327 |
 | **6.2.3** | [DELETED, DUPLICATE OF 6.2.5] | | | | |
 | **6.2.4** | Verify that the application is designed with crypto agility such that random number, encryption or hashing algorithms, key lengths, rounds, ciphers or modes can be reconfigured, upgraded, or swapped at any time, to protect against cryptographic breaks. Similarly, it must also be possible to replace keys and passwords and re-encrypt data. This should allow for seamless upgrades to post-quantum cryptography (PQC), once PQC standards are fully established. | | ✓ | ✓ | 320 |
-| **6.2.5** | [SPLIT TO 6.5.1, 6.5.2, 6.6.3]. | | | | |
-| **6.2.6** | [MOVED TO 6.5.3]| | | | |
-| **6.2.7** | [MOVED TO 6.5.4]| | | | |
+| **6.2.5** | [SPLIT TO 6.5.1, 6.5.2, 6.6.3] | | | | |
+| **6.2.6** | [MOVED TO 6.5.3] | | | | |
+| **6.2.7** | [MOVED TO 6.5.4] | | | | |
 | **6.2.8** | Verify that all cryptographic operations are constant-time, with no 'short-circuit' operations in comparisons, calculations, or returns, to avoid leaking information. | | | ✓ | 385 |
 | **6.2.9** | [ADDED] All cryptographic primitives MUST utilize a minimum of 128-bits of security, with exceptions only made for equipment or applications approaching end of life, where the requirement is at least 112-bits of security for all cryptography. | ✓ | ✓ | ✓ | 311 |
 
@@ -86,7 +86,7 @@ Cipher algorithms such as AES and CHACHA20 form the backbone of modern cryptogra
 | **6.5.2** | [ADDED, SPLIT FROM 6.2.5, LEVEL L2 > L1] Verify that insecure ciphers, including Triple-DES and Blowfish, are not used but secure ciphers and modes** such as AES with GCM are. | ✓ | ✓ | ✓ | 326 |
 | **6.5.3** | [MOVED FROM 6.2.6, LEVEL L2 > L3] Verify that nonces, initialization vectors, and other single-use numbers are not used for more than one encryption key/data-element pair. The method of generation must be appropriate for the algorithm being used. | | | ✓ | 326 |
 | **6.5.4** | [MOVED FROM 6.2.7] Verify that encrypted data is authenticated via signatures, including unencrypted tokens being used for secure access control, as well as through authenticated cipher modes or HMAC for protection against unauthorized modification. | | | ✓ | 326 |
-| **6.5.5** | [ADDED] Verify that any authenticated signatures are operating in encrypt-then-MAC or encrypt-then-hash modes as required.| | | ✓ | 326 |
+| **6.5.5** | [ADDED] Verify that any authenticated signatures are operating in encrypt-then-MAC or encrypt-then-hash modes as required. | | | ✓ | 326 |
 
 ## V6.6 Hashing and Hash-based Functions
 

5.0/en/0x21-V13-API.md

@@ -33,7 +33,7 @@ Note: Due to issues with XXE attacks against DTDs, DTD validation should not be
 | # | Description | L1 | L2 | L3 | CWE |
 | :---: | :--- | :---: | :---: | :---: | :---: |
 | **13.2.1** | [MOVED TO 13.6.2] | | | | |
-| **13.2.2** | [MODIFIED, MERGED FROM 13.3.1, LEVEL L1 > L3] Verify that structured data objects are validated to ensure they are properly formed, followed by validation of each input field before any processing of that data takes place. This could involve implementing schema validation for formats like JSON and XML.| | |✓|20|
+| **13.2.2** | [MODIFIED, MERGED FROM 13.3.1, LEVEL L1 > L3] Verify that structured data objects are validated to ensure they are properly formed, followed by validation of each input field before any processing of that data takes place. This could involve implementing schema validation for formats like JSON and XML. | | | ✓ | 20 |
 | **13.2.3** | [DELETED, MERGED TO 50.3.1] | | | | |
 | **13.2.4** | [DELETED, DUPLICATE OF 11.1.4] | | | | |
 | **13.2.5** | Verify that REST services explicitly check the incoming Content-Type to be the expected one, such as application/xml or application/json. | | ✓ | ✓ | 436 |