From a2af71d3e0ce5b1bdc35e347a8bf101cdc27ce0b Mon Sep 17 00:00:00 2001 From: Uncle Joe <1244005+sydseter@users.noreply.github.com> Date: Tue, 15 Jul 2025 10:46:35 +0200 Subject: [PATCH 01/17] Fixes https://github.com/OWASP/mastg/issues/2588 --- weaknesses/MASVS-CRYPTO/MASWE-0024.md | 37 ++++++++++++++++++--------- 1 file changed, 25 insertions(+), 12 deletions(-) diff --git a/weaknesses/MASVS-CRYPTO/MASWE-0024.md b/weaknesses/MASVS-CRYPTO/MASWE-0024.md index c0d5c0a..85f850d 100644 --- a/weaknesses/MASVS-CRYPTO/MASWE-0024.md +++ b/weaknesses/MASVS-CRYPTO/MASWE-0024.md @@ -1,7 +1,7 @@ --- title: Improper Use of Message Authentication Code (MAC) id: MASWE-0024 -alias: improper-mac +alias: weak-mac platform: [android, ios] profiles: [L1, L2] mappings: @@ -17,17 +17,30 @@ refs: - https://web.archive.org/web/20170810051504/http://www.tcs.hut.fi/old/papers/aura/aura-csfws97.pdf - https://en.wikipedia.org/wiki/Replay_attack draft: - description: Improper use of MACs in security sensitive contexts affecting data integrity. - topics: - - Using HMAC with keys with insufficient entropy - - Using HMAC with missing timestamp (or nonce) - - Using MAC‑then‑encrypt or encrypt‑then‑MAC incorrectly, leaking information via timing or error messages - - Allowing predictors (users or attackers) to control data inputs, creating scenarios where forged or replayed tags bypass integrity checks. - - Hash functions lacking collision resistance (e.g., MD5 or SHA‑1 used in HMAC) - - Use of non‑cryptographic checksums (e.g., CRC‑32 instead of HMAC) - - MAC constructions that fail outside narrow assumptions (e.g., raw CBC‑MAC on variable‑length messages) - - Tags that are too short significantly lower the effort required for forgery -status: placeholder + description: Improper use of MAC. E.g. allowing the user to control the input. + may expose cryptographic vulnerabilities, affecting data integrity. + topics: null +status: draft --- +Improper use of a MAC by e.g., generating a MAC over a message without the timestamp can make the application susceptible for replay attacks. +Another common issue is using an HMAC with any type of general based hashing algorithm like MD5, SHA-1, SHA-2 or even SHA-3 on low-entropy input like user supplied passwords and pins. HMAC aren't designed for low-entropy inputs or low-entropy keys. Doing so will result in producing "weak" message digests that easily can be exploited. + +A deprecated HMAC implementation may contain bugs that could compromise the authenticity of the data. + +## Impact + +- **Loss of Integrity and authenticity**: Improper use of MAC may result in replay attacks or, in worse case, broken authentication that could compromise the integrity of a system. +- **Loss of Confidentiality**: Using MAC for other purposes than authentication may lead to a complete loss of confidentiality. + +## Modes of Introduction + +- **Not including a timestamp**: Creating a MAC for message authentication without using a proper timestamp that can be validated for the possibility of replay-attacks. +- **Using a MAC with low-entropy keys**: Using low-entropy inputs or low-entropy keys as input to a HMAC. + +## Mitigations + +- **Use MAC with a timestamp**: Generate the MAC over a message with the timestamp included. This should protect the application against replay attacks within a reasonable amount of time. Reasonable, meaning a time frame that is short enough to prevent an attacker from sending an identical message and long enough to allow the message to be sent and digested. +- **Do not use HMAC together with a low-entropy key**: Ensure the keys used are generated using cryptographically secure PRNGs (CSPRNG) generate random numbers that pass statistical randomness tests, and are resilient against prediction attacks. +- **Do not use deprecated HMAC implementations**: Deprecated HMAC implementations could contain errors that allow for collision attacks. Therefore, only use recommended libraries and functions. From d6381c7d03a3f94be2cafcfd73e0171a3f9063a3 Mon Sep 17 00:00:00 2001 From: Uncle Joe <1244005+sydseter@users.noreply.github.com> Date: Tue, 15 Jul 2025 13:47:31 +0200 Subject: [PATCH 02/17] change id --- weaknesses/MASVS-CRYPTO/MASWE-0024.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/weaknesses/MASVS-CRYPTO/MASWE-0024.md b/weaknesses/MASVS-CRYPTO/MASWE-0024.md index 85f850d..c2de2ef 100644 --- a/weaknesses/MASVS-CRYPTO/MASWE-0024.md +++ b/weaknesses/MASVS-CRYPTO/MASWE-0024.md @@ -1,7 +1,7 @@ --- title: Improper Use of Message Authentication Code (MAC) id: MASWE-0024 -alias: weak-mac +alias: improper-mac platform: [android, ios] profiles: [L1, L2] mappings: From dedf0929a2dae5cfc43affaa29f646c273a2d6ed Mon Sep 17 00:00:00 2001 From: Uncle Joe <1244005+sydseter@users.noreply.github.com> Date: Tue, 15 Jul 2025 14:27:07 +0200 Subject: [PATCH 03/17] Change status --- weaknesses/MASVS-CRYPTO/MASWE-0024.md | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/weaknesses/MASVS-CRYPTO/MASWE-0024.md b/weaknesses/MASVS-CRYPTO/MASWE-0024.md index c2de2ef..92f9352 100644 --- a/weaknesses/MASVS-CRYPTO/MASWE-0024.md +++ b/weaknesses/MASVS-CRYPTO/MASWE-0024.md @@ -16,13 +16,13 @@ refs: - https://datatracker.ietf.org/doc/html/rfc6151 - https://web.archive.org/web/20170810051504/http://www.tcs.hut.fi/old/papers/aura/aura-csfws97.pdf - https://en.wikipedia.org/wiki/Replay_attack -draft: - description: Improper use of MAC. E.g. allowing the user to control the input. - may expose cryptographic vulnerabilities, affecting data integrity. - topics: null -status: draft + +status: new --- + +## Overview + Improper use of a MAC by e.g., generating a MAC over a message without the timestamp can make the application susceptible for replay attacks. Another common issue is using an HMAC with any type of general based hashing algorithm like MD5, SHA-1, SHA-2 or even SHA-3 on low-entropy input like user supplied passwords and pins. HMAC aren't designed for low-entropy inputs or low-entropy keys. Doing so will result in producing "weak" message digests that easily can be exploited. From 167b9c2fecf4763bf723db43f36fa4c2bd8ba082 Mon Sep 17 00:00:00 2001 From: Uncle Joe <1244005+sydseter@users.noreply.github.com> Date: Tue, 15 Jul 2025 17:24:31 +0200 Subject: [PATCH 04/17] Add back description --- weaknesses/MASVS-CRYPTO/MASWE-0024.md | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/weaknesses/MASVS-CRYPTO/MASWE-0024.md b/weaknesses/MASVS-CRYPTO/MASWE-0024.md index 92f9352..fc82aa4 100644 --- a/weaknesses/MASVS-CRYPTO/MASWE-0024.md +++ b/weaknesses/MASVS-CRYPTO/MASWE-0024.md @@ -16,7 +16,8 @@ refs: - https://datatracker.ietf.org/doc/html/rfc6151 - https://web.archive.org/web/20170810051504/http://www.tcs.hut.fi/old/papers/aura/aura-csfws97.pdf - https://en.wikipedia.org/wiki/Replay_attack - +description: Improper use of MAC. E.g. allowing the user to control the input may expose cryptographic vulnerabilities, affecting data integrity. +topics: null status: new --- From ba0fef2c0c3baa69fbaca5aaed45ea5cefdae792 Mon Sep 17 00:00:00 2001 From: Uncle Joe <1244005+sydseter@users.noreply.github.com> Date: Tue, 15 Jul 2025 17:32:00 +0200 Subject: [PATCH 05/17] Reconstruct topics and description --- weaknesses/MASVS-CRYPTO/MASWE-0024.md | 12 ++++++++++-- 1 file changed, 10 insertions(+), 2 deletions(-) diff --git a/weaknesses/MASVS-CRYPTO/MASWE-0024.md b/weaknesses/MASVS-CRYPTO/MASWE-0024.md index fc82aa4..c12dd8f 100644 --- a/weaknesses/MASVS-CRYPTO/MASWE-0024.md +++ b/weaknesses/MASVS-CRYPTO/MASWE-0024.md @@ -16,8 +16,16 @@ refs: - https://datatracker.ietf.org/doc/html/rfc6151 - https://web.archive.org/web/20170810051504/http://www.tcs.hut.fi/old/papers/aura/aura-csfws97.pdf - https://en.wikipedia.org/wiki/Replay_attack -description: Improper use of MAC. E.g. allowing the user to control the input may expose cryptographic vulnerabilities, affecting data integrity. -topics: null +description: Improper use of MACs in security sensitive contexts affecting data integrity. +topics: +- Using HMAC with keys with insufficient entropy +- Using HMAC with missing timestamp (or nonce) +- Using MAC‑then‑encrypt or encrypt‑then‑MAC incorrectly, leaking information via timing or error messages +- Allowing predictors (users or attackers) to control data inputs, creating scenarios where forged or replayed tags bypass integrity checks. +- Hash functions lacking collision resistance (e.g., MD5 or SHA‑1 used in HMAC) +- Use of non‑cryptographic checksums (e.g., CRC‑32 instead of HMAC) +- MAC constructions that fail outside narrow assumptions (e.g., raw CBC‑MAC on variable‑length messages) +- Tags that are too short significantly lower the effort required for forgery status: new --- From 4b1d324d36c96de7f711e6222406cdec5449f862 Mon Sep 17 00:00:00 2001 From: Uncle Joe <1244005+sydseter@users.noreply.github.com> Date: Wed, 16 Jul 2025 13:06:38 +0200 Subject: [PATCH 06/17] Remove description and topics --- weaknesses/MASVS-CRYPTO/MASWE-0024.md | 11 +---------- 1 file changed, 1 insertion(+), 10 deletions(-) diff --git a/weaknesses/MASVS-CRYPTO/MASWE-0024.md b/weaknesses/MASVS-CRYPTO/MASWE-0024.md index c12dd8f..92f9352 100644 --- a/weaknesses/MASVS-CRYPTO/MASWE-0024.md +++ b/weaknesses/MASVS-CRYPTO/MASWE-0024.md @@ -16,16 +16,7 @@ refs: - https://datatracker.ietf.org/doc/html/rfc6151 - https://web.archive.org/web/20170810051504/http://www.tcs.hut.fi/old/papers/aura/aura-csfws97.pdf - https://en.wikipedia.org/wiki/Replay_attack -description: Improper use of MACs in security sensitive contexts affecting data integrity. -topics: -- Using HMAC with keys with insufficient entropy -- Using HMAC with missing timestamp (or nonce) -- Using MAC‑then‑encrypt or encrypt‑then‑MAC incorrectly, leaking information via timing or error messages -- Allowing predictors (users or attackers) to control data inputs, creating scenarios where forged or replayed tags bypass integrity checks. -- Hash functions lacking collision resistance (e.g., MD5 or SHA‑1 used in HMAC) -- Use of non‑cryptographic checksums (e.g., CRC‑32 instead of HMAC) -- MAC constructions that fail outside narrow assumptions (e.g., raw CBC‑MAC on variable‑length messages) -- Tags that are too short significantly lower the effort required for forgery + status: new --- From 8eff3e3dd25eeb54908ab988adb12b3f492af58b Mon Sep 17 00:00:00 2001 From: Uncle Joe <1244005+sydseter@users.noreply.github.com> Date: Wed, 16 Jul 2025 13:08:38 +0200 Subject: [PATCH 07/17] Remove new line --- weaknesses/MASVS-CRYPTO/MASWE-0024.md | 1 - 1 file changed, 1 deletion(-) diff --git a/weaknesses/MASVS-CRYPTO/MASWE-0024.md b/weaknesses/MASVS-CRYPTO/MASWE-0024.md index 92f9352..014f71a 100644 --- a/weaknesses/MASVS-CRYPTO/MASWE-0024.md +++ b/weaknesses/MASVS-CRYPTO/MASWE-0024.md @@ -16,7 +16,6 @@ refs: - https://datatracker.ietf.org/doc/html/rfc6151 - https://web.archive.org/web/20170810051504/http://www.tcs.hut.fi/old/papers/aura/aura-csfws97.pdf - https://en.wikipedia.org/wiki/Replay_attack - status: new --- From c9122d19e60bd40efe5443c2aa135984153e2860 Mon Sep 17 00:00:00 2001 From: Uncle Joe <1244005+sydseter@users.noreply.github.com> Date: Wed, 16 Jul 2025 13:19:41 +0200 Subject: [PATCH 08/17] Add back draft state for now --- weaknesses/MASVS-CRYPTO/MASWE-0024.md | 13 ++++++++++++- 1 file changed, 12 insertions(+), 1 deletion(-) diff --git a/weaknesses/MASVS-CRYPTO/MASWE-0024.md b/weaknesses/MASVS-CRYPTO/MASWE-0024.md index 014f71a..4bfdf35 100644 --- a/weaknesses/MASVS-CRYPTO/MASWE-0024.md +++ b/weaknesses/MASVS-CRYPTO/MASWE-0024.md @@ -16,7 +16,18 @@ refs: - https://datatracker.ietf.org/doc/html/rfc6151 - https://web.archive.org/web/20170810051504/http://www.tcs.hut.fi/old/papers/aura/aura-csfws97.pdf - https://en.wikipedia.org/wiki/Replay_attack -status: new +draft: + description: Improper use of MACs in security sensitive contexts affecting data integrity. + topics: + - Using HMAC with keys with insufficient entropy + - Using HMAC with missing timestamp (or nonce) + - Using MAC‑then‑encrypt or encrypt‑then‑MAC incorrectly, leaking information via timing or error messages + - Allowing predictors (users or attackers) to control data inputs, creating scenarios where forged or replayed tags bypass integrity checks. + - Hash functions lacking collision resistance (e.g., MD5 or SHA‑1 used in HMAC) + - Use of non‑cryptographic checksums (e.g., CRC‑32 instead of HMAC) + - MAC constructions that fail outside narrow assumptions (e.g., raw CBC‑MAC on variable‑length messages) + - Tags that are too short significantly lower the effort required for forgery +status: placeholder --- From b9ab458dfa0f8461e7d24401d693d28819670e6d Mon Sep 17 00:00:00 2001 From: Uncle Joe <1244005+sydseter@users.noreply.github.com> Date: Mon, 3 Nov 2025 11:00:36 +0100 Subject: [PATCH 09/17] Enhance clarity on MAC usage and associated risks Clarified the overview and impact of improper MAC usage, emphasizing the risks of MAC forgeries and the need for proper sequence numbers or timestamps. Updated details on the consequences of using HMAC with low-entropy inputs and the importance of avoiding deprecated implementations. --- weaknesses/MASVS-CRYPTO/MASWE-0024.md | 7 ++++--- 1 file changed, 4 insertions(+), 3 deletions(-) diff --git a/weaknesses/MASVS-CRYPTO/MASWE-0024.md b/weaknesses/MASVS-CRYPTO/MASWE-0024.md index 4bfdf35..7c43b77 100644 --- a/weaknesses/MASVS-CRYPTO/MASWE-0024.md +++ b/weaknesses/MASVS-CRYPTO/MASWE-0024.md @@ -33,7 +33,7 @@ status: placeholder ## Overview -Improper use of a MAC by e.g., generating a MAC over a message without the timestamp can make the application susceptible for replay attacks. +Improper use of a MAC by e.g., not using proper sequence numbers or timestamps, may allow MAC forgeries making it possible to compromiss the authenticity and integrity of the data. Another common issue is using an HMAC with any type of general based hashing algorithm like MD5, SHA-1, SHA-2 or even SHA-3 on low-entropy input like user supplied passwords and pins. HMAC aren't designed for low-entropy inputs or low-entropy keys. Doing so will result in producing "weak" message digests that easily can be exploited. @@ -41,12 +41,13 @@ A deprecated HMAC implementation may contain bugs that could compromise the auth ## Impact -- **Loss of Integrity and authenticity**: Improper use of MAC may result in replay attacks or, in worse case, broken authentication that could compromise the integrity of a system. +- **Loss of authenticity**: Improper use of MAC may allow an attacker to compromise the authenticity of the data making the data appear authentic. +- **Loss of Integrity**: Improper use of MAC may allow an attacker to alter the data thereby compromising it's integrity. - **Loss of Confidentiality**: Using MAC for other purposes than authentication may lead to a complete loss of confidentiality. ## Modes of Introduction -- **Not including a timestamp**: Creating a MAC for message authentication without using a proper timestamp that can be validated for the possibility of replay-attacks. +- **Not including a timestamp**: Creating a MAC for message authentication without using a proper timestamp that can be validated to protect against MAC forgery. - **Using a MAC with low-entropy keys**: Using low-entropy inputs or low-entropy keys as input to a HMAC. ## Mitigations From a7c258dc721bad74bb8e51af4d26557822a6b0be Mon Sep 17 00:00:00 2001 From: Uncle Joe <1244005+sydseter@users.noreply.github.com> Date: Mon, 3 Nov 2025 11:50:47 +0100 Subject: [PATCH 10/17] Clarify MAC usage issues and mitigation strategies Updated the overview and mitigations sections to clarify issues with MAC usage, including nonce and timestamp importance, and deprecated HMAC implementations. Removed redundant information and improved clarity. --- weaknesses/MASVS-CRYPTO/MASWE-0024.md | 16 +++++++++++----- 1 file changed, 11 insertions(+), 5 deletions(-) diff --git a/weaknesses/MASVS-CRYPTO/MASWE-0024.md b/weaknesses/MASVS-CRYPTO/MASWE-0024.md index 7c43b77..6b262d1 100644 --- a/weaknesses/MASVS-CRYPTO/MASWE-0024.md +++ b/weaknesses/MASVS-CRYPTO/MASWE-0024.md @@ -33,11 +33,10 @@ status: placeholder ## Overview -Improper use of a MAC by e.g., not using proper sequence numbers or timestamps, may allow MAC forgeries making it possible to compromiss the authenticity and integrity of the data. - -Another common issue is using an HMAC with any type of general based hashing algorithm like MD5, SHA-1, SHA-2 or even SHA-3 on low-entropy input like user supplied passwords and pins. HMAC aren't designed for low-entropy inputs or low-entropy keys. Doing so will result in producing "weak" message digests that easily can be exploited. - -A deprecated HMAC implementation may contain bugs that could compromise the authenticity of the data. +Improper use of a MAC by e.g., not using proper nonces or timestamps, may allow MAC forgeries making it possible to compromiss the authenticity and integrity of the data. +Not applying the MAC in the correct order when using CBC mode during encryption e.g., creating the MAC before encrypting the data instead of after to ensure the authenticity and integrity of the encrypted data. +Another common issue is using an HMAC with any type of general based hashing algorithm like MD5, SHA-1, SHA-2 or even SHA-3 on low-entropy input like user supplied passwords, pins or other user controlled predictors. HMAC aren't designed for low-entropy inputs or low-entropy keys. Doing so will result in producing "weak" message digests that easily can be exploited. +Deprecateded or risky HMAC implementation like HMAC-MD5 or HMAC-SHA1 are vulnerable to collision attacks that would compromise the authenticity and integrity of the data. Collision attacks can also be made possible through truncating the HMAC digest. In the case truncating is necessary for interoperability, never truncate the digest below 128 bits and use the full HMAC whenever possible. Finally, never create checksums using none cryptographically secure algorithms like CRC‑32 not meant for cryptographic purposes. ## Impact @@ -49,9 +48,16 @@ A deprecated HMAC implementation may contain bugs that could compromise the auth - **Not including a timestamp**: Creating a MAC for message authentication without using a proper timestamp that can be validated to protect against MAC forgery. - **Using a MAC with low-entropy keys**: Using low-entropy inputs or low-entropy keys as input to a HMAC. +- **Using a MAC with a predictor**: Using data that is controlled by the user for the purpose of creating a HMAC signature. +- **Using a deprecated or risky MAC implementation**: Using e.g: HMAC-MD5 or HMAC-SHA1 which are known to be vulnerable to collision attacks. +- **Using a none cryptographically secure algorithms**: Using CRC‑32 that not is meant to be used for cryptographic purposes. +- **Truncating the HMAC digest too much**: Truncating the final HMAC digest making it shorter than 128 bit. ## Mitigations - **Use MAC with a timestamp**: Generate the MAC over a message with the timestamp included. This should protect the application against replay attacks within a reasonable amount of time. Reasonable, meaning a time frame that is short enough to prevent an attacker from sending an identical message and long enough to allow the message to be sent and digested. - **Do not use HMAC together with a low-entropy key**: Ensure the keys used are generated using cryptographically secure PRNGs (CSPRNG) generate random numbers that pass statistical randomness tests, and are resilient against prediction attacks. +- **Do not use a MAC together with a predictor**: Ensure HMACs - **Do not use deprecated HMAC implementations**: Deprecated HMAC implementations could contain errors that allow for collision attacks. Therefore, only use recommended libraries and functions. +- **Do not use none cryptographically secure algorithms**: Algorithms like e.g. CRC‑32 is not meant to be used for cryptographic purposes. +- **Use the full HMAC digest and avoid truncation**: When possible, always use the full HMAC digest. When truncating is necessary, never make it shorter than 128 bit. From 9df0ed1570d047c4694f1a1cfa90743eb21c39a1 Mon Sep 17 00:00:00 2001 From: Uncle Joe <1244005+sydseter@users.noreply.github.com> Date: Mon, 3 Nov 2025 12:45:21 +0100 Subject: [PATCH 11/17] correct spelling --- weaknesses/MASVS-CRYPTO/MASWE-0024.md | 24 ++++++++++++------------ 1 file changed, 12 insertions(+), 12 deletions(-) diff --git a/weaknesses/MASVS-CRYPTO/MASWE-0024.md b/weaknesses/MASVS-CRYPTO/MASWE-0024.md index 6b262d1..0dc034f 100644 --- a/weaknesses/MASVS-CRYPTO/MASWE-0024.md +++ b/weaknesses/MASVS-CRYPTO/MASWE-0024.md @@ -33,25 +33,25 @@ status: placeholder ## Overview -Improper use of a MAC by e.g., not using proper nonces or timestamps, may allow MAC forgeries making it possible to compromiss the authenticity and integrity of the data. -Not applying the MAC in the correct order when using CBC mode during encryption e.g., creating the MAC before encrypting the data instead of after to ensure the authenticity and integrity of the encrypted data. -Another common issue is using an HMAC with any type of general based hashing algorithm like MD5, SHA-1, SHA-2 or even SHA-3 on low-entropy input like user supplied passwords, pins or other user controlled predictors. HMAC aren't designed for low-entropy inputs or low-entropy keys. Doing so will result in producing "weak" message digests that easily can be exploited. -Deprecateded or risky HMAC implementation like HMAC-MD5 or HMAC-SHA1 are vulnerable to collision attacks that would compromise the authenticity and integrity of the data. Collision attacks can also be made possible through truncating the HMAC digest. In the case truncating is necessary for interoperability, never truncate the digest below 128 bits and use the full HMAC whenever possible. Finally, never create checksums using none cryptographically secure algorithms like CRC‑32 not meant for cryptographic purposes. +Improper use of a MAC, e.g., not using proper nonces or timestamps, may allow MAC forgeries, making it possible to compromise the authenticity and integrity of the data. +Not applying the MAC in the correct order when using CBC mode during encryption, e.g., creating the MAC before encrypting the data instead of after to ensure the authenticity and integrity of the encrypted data. +Another common issue is using an HMAC with any type of general-based hashing algorithm like MD5, SHA-1, SHA-2 or even SHA-3 on low-entropy input like user-supplied passwords, pins or other user-controlled predictors. HMACs aren't designed for low-entropy inputs or low-entropy keys. Doing so will result in producing "weak" message digests that can easily be exploited. +Deprecated or risky HMAC implementations like HMAC-MD5 or HMAC-SHA1 are vulnerable to collision attacks that would compromise the authenticity and integrity of the data. Collision attacks can also be made possible through truncating the HMAC digest. If truncating is necessary for interoperability, never truncate the digest below 128 bits and use the full HMAC whenever possible. Finally, never create checksums using non-cryptographically secure algorithms like CRC‑32, which are not meant for cryptographic purposes. ## Impact -- **Loss of authenticity**: Improper use of MAC may allow an attacker to compromise the authenticity of the data making the data appear authentic. -- **Loss of Integrity**: Improper use of MAC may allow an attacker to alter the data thereby compromising it's integrity. +- **Loss of authenticity**: Improper use of MAC may allow an attacker to compromise the authenticity of the data, making the data appear authentic. +- **Loss of Integrity**: Improper use of MAC may allow an attacker to alter the data, thereby compromising its integrity. - **Loss of Confidentiality**: Using MAC for other purposes than authentication may lead to a complete loss of confidentiality. ## Modes of Introduction - **Not including a timestamp**: Creating a MAC for message authentication without using a proper timestamp that can be validated to protect against MAC forgery. - **Using a MAC with low-entropy keys**: Using low-entropy inputs or low-entropy keys as input to a HMAC. -- **Using a MAC with a predictor**: Using data that is controlled by the user for the purpose of creating a HMAC signature. -- **Using a deprecated or risky MAC implementation**: Using e.g: HMAC-MD5 or HMAC-SHA1 which are known to be vulnerable to collision attacks. -- **Using a none cryptographically secure algorithms**: Using CRC‑32 that not is meant to be used for cryptographic purposes. -- **Truncating the HMAC digest too much**: Truncating the final HMAC digest making it shorter than 128 bit. +- **Using a MAC with a predictor**: Using data controlled by the user to create a HMAC signature. +- **Using a deprecated or risky MAC implementation**: Using e.g, HMAC-MD5 or HMAC-SHA1, which are known to be vulnerable to collision attacks. +- **Using a non-cryptographically secure algorithm**: Using CRC‑32, which is not meant to be used for cryptographic purposes. +- **Truncating the HMAC digest too much**: Truncating the final HMAC digest makes it shorter than 128 bits. ## Mitigations @@ -59,5 +59,5 @@ Deprecateded or risky HMAC implementation like HMAC-MD5 or HMAC-SHA1 are vulnera - **Do not use HMAC together with a low-entropy key**: Ensure the keys used are generated using cryptographically secure PRNGs (CSPRNG) generate random numbers that pass statistical randomness tests, and are resilient against prediction attacks. - **Do not use a MAC together with a predictor**: Ensure HMACs - **Do not use deprecated HMAC implementations**: Deprecated HMAC implementations could contain errors that allow for collision attacks. Therefore, only use recommended libraries and functions. -- **Do not use none cryptographically secure algorithms**: Algorithms like e.g. CRC‑32 is not meant to be used for cryptographic purposes. -- **Use the full HMAC digest and avoid truncation**: When possible, always use the full HMAC digest. When truncating is necessary, never make it shorter than 128 bit. +- **Do not use non-cryptographically secure algorithms**: Algorithms like e.g. CRC‑32 is not meant to be used for cryptographic purposes. +- **Use the complete HMAC digest and avoid truncation**: When possible, always use the complete HMAC digest. When truncating is necessary, never make it shorter than 128 bits. From 13c9257760e939b00402485fb69a7983e09c4a40 Mon Sep 17 00:00:00 2001 From: Carlos Holguera Date: Sat, 15 Nov 2025 14:37:13 +0100 Subject: [PATCH 12/17] Apply suggestions from code review Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com> --- weaknesses/MASVS-CRYPTO/MASWE-0024.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/weaknesses/MASVS-CRYPTO/MASWE-0024.md b/weaknesses/MASVS-CRYPTO/MASWE-0024.md index 0dc034f..e8ceab3 100644 --- a/weaknesses/MASVS-CRYPTO/MASWE-0024.md +++ b/weaknesses/MASVS-CRYPTO/MASWE-0024.md @@ -35,7 +35,7 @@ status: placeholder Improper use of a MAC, e.g., not using proper nonces or timestamps, may allow MAC forgeries, making it possible to compromise the authenticity and integrity of the data. Not applying the MAC in the correct order when using CBC mode during encryption, e.g., creating the MAC before encrypting the data instead of after to ensure the authenticity and integrity of the encrypted data. -Another common issue is using an HMAC with any type of general-based hashing algorithm like MD5, SHA-1, SHA-2 or even SHA-3 on low-entropy input like user-supplied passwords, pins or other user-controlled predictors. HMACs aren't designed for low-entropy inputs or low-entropy keys. Doing so will result in producing "weak" message digests that can easily be exploited. +Another common issue is using an HMAC with any type of general-purpose hashing algorithm (like MD5, SHA-1, SHA-2, or even SHA-3) on low-entropy input, such as user-supplied passwords, PINs, or other user-controlled predictors. HMACs are not designed for use with low-entropy inputs or low-entropy keys. Using HMACs in this way will result in "weak" message digests that can easily be exploited. Deprecated or risky HMAC implementations like HMAC-MD5 or HMAC-SHA1 are vulnerable to collision attacks that would compromise the authenticity and integrity of the data. Collision attacks can also be made possible through truncating the HMAC digest. If truncating is necessary for interoperability, never truncate the digest below 128 bits and use the full HMAC whenever possible. Finally, never create checksums using non-cryptographically secure algorithms like CRC‑32, which are not meant for cryptographic purposes. ## Impact @@ -57,7 +57,7 @@ Deprecated or risky HMAC implementations like HMAC-MD5 or HMAC-SHA1 are vulnerab - **Use MAC with a timestamp**: Generate the MAC over a message with the timestamp included. This should protect the application against replay attacks within a reasonable amount of time. Reasonable, meaning a time frame that is short enough to prevent an attacker from sending an identical message and long enough to allow the message to be sent and digested. - **Do not use HMAC together with a low-entropy key**: Ensure the keys used are generated using cryptographically secure PRNGs (CSPRNG) generate random numbers that pass statistical randomness tests, and are resilient against prediction attacks. -- **Do not use a MAC together with a predictor**: Ensure HMACs +- **Do not use a MAC together with a predictor**: Ensure that all inputs to the MAC are unpredictable and not controlled by the user or attacker. Never use user-controllable or predictable data as input to a MAC, as this can allow attackers to forge valid MACs. - **Do not use deprecated HMAC implementations**: Deprecated HMAC implementations could contain errors that allow for collision attacks. Therefore, only use recommended libraries and functions. -- **Do not use non-cryptographically secure algorithms**: Algorithms like e.g. CRC‑32 is not meant to be used for cryptographic purposes. +- **Do not use non-cryptographically secure algorithms**: Algorithms like e.g. CRC‑32 are not meant to be used for cryptographic purposes. - **Use the complete HMAC digest and avoid truncation**: When possible, always use the complete HMAC digest. When truncating is necessary, never make it shorter than 128 bits. From f36ad8e08ae12b4fd9f4532f89f1ff7642eefb6f Mon Sep 17 00:00:00 2001 From: Uncle Joe <1244005+sydseter@users.noreply.github.com> Date: Tue, 25 Nov 2025 08:52:41 +0100 Subject: [PATCH 13/17] Update weaknesses/MASVS-CRYPTO/MASWE-0024.md Co-authored-by: Dionysis Lorentzos --- weaknesses/MASVS-CRYPTO/MASWE-0024.md | 1 - 1 file changed, 1 deletion(-) diff --git a/weaknesses/MASVS-CRYPTO/MASWE-0024.md b/weaknesses/MASVS-CRYPTO/MASWE-0024.md index e8ceab3..f303c80 100644 --- a/weaknesses/MASVS-CRYPTO/MASWE-0024.md +++ b/weaknesses/MASVS-CRYPTO/MASWE-0024.md @@ -34,7 +34,6 @@ status: placeholder ## Overview Improper use of a MAC, e.g., not using proper nonces or timestamps, may allow MAC forgeries, making it possible to compromise the authenticity and integrity of the data. -Not applying the MAC in the correct order when using CBC mode during encryption, e.g., creating the MAC before encrypting the data instead of after to ensure the authenticity and integrity of the encrypted data. Another common issue is using an HMAC with any type of general-purpose hashing algorithm (like MD5, SHA-1, SHA-2, or even SHA-3) on low-entropy input, such as user-supplied passwords, PINs, or other user-controlled predictors. HMACs are not designed for use with low-entropy inputs or low-entropy keys. Using HMACs in this way will result in "weak" message digests that can easily be exploited. Deprecated or risky HMAC implementations like HMAC-MD5 or HMAC-SHA1 are vulnerable to collision attacks that would compromise the authenticity and integrity of the data. Collision attacks can also be made possible through truncating the HMAC digest. If truncating is necessary for interoperability, never truncate the digest below 128 bits and use the full HMAC whenever possible. Finally, never create checksums using non-cryptographically secure algorithms like CRC‑32, which are not meant for cryptographic purposes. From 4832e51969a2511eed5da95d1c354ab4d104f781 Mon Sep 17 00:00:00 2001 From: Uncle Joe <1244005+sydseter@users.noreply.github.com> Date: Tue, 25 Nov 2025 08:56:09 +0100 Subject: [PATCH 14/17] Update MASWE-0024.md --- weaknesses/MASVS-CRYPTO/MASWE-0024.md | 1 + 1 file changed, 1 insertion(+) diff --git a/weaknesses/MASVS-CRYPTO/MASWE-0024.md b/weaknesses/MASVS-CRYPTO/MASWE-0024.md index f303c80..21d493c 100644 --- a/weaknesses/MASVS-CRYPTO/MASWE-0024.md +++ b/weaknesses/MASVS-CRYPTO/MASWE-0024.md @@ -51,6 +51,7 @@ Deprecated or risky HMAC implementations like HMAC-MD5 or HMAC-SHA1 are vulnerab - **Using a deprecated or risky MAC implementation**: Using e.g, HMAC-MD5 or HMAC-SHA1, which are known to be vulnerable to collision attacks. - **Using a non-cryptographically secure algorithm**: Using CRC‑32, which is not meant to be used for cryptographic purposes. - **Truncating the HMAC digest too much**: Truncating the final HMAC digest makes it shorter than 128 bits. +- **Not applying the MAC in the correct order**: When using CBC mode during encryption, e.g., incorrectly creating the MAC before encrypting the data instead of after, to ensure the authenticity and integrity of the encrypted data. ## Mitigations From e4f1109cffc821d9d06c3c4eb2af3ae00f3df6e1 Mon Sep 17 00:00:00 2001 From: Uncle Joe <1244005+sydseter@users.noreply.github.com> Date: Tue, 25 Nov 2025 10:42:22 +0100 Subject: [PATCH 15/17] Update MASWE-0024 with new HMAC mitigation Added a new mitigation recommendation to use HMAC instead of raw hash constructions for tamper detection. --- weaknesses/MASVS-CRYPTO/MASWE-0024.md | 2 ++ 1 file changed, 2 insertions(+) diff --git a/weaknesses/MASVS-CRYPTO/MASWE-0024.md b/weaknesses/MASVS-CRYPTO/MASWE-0024.md index 21d493c..ec93930 100644 --- a/weaknesses/MASVS-CRYPTO/MASWE-0024.md +++ b/weaknesses/MASVS-CRYPTO/MASWE-0024.md @@ -52,6 +52,7 @@ Deprecated or risky HMAC implementations like HMAC-MD5 or HMAC-SHA1 are vulnerab - **Using a non-cryptographically secure algorithm**: Using CRC‑32, which is not meant to be used for cryptographic purposes. - **Truncating the HMAC digest too much**: Truncating the final HMAC digest makes it shorter than 128 bits. - **Not applying the MAC in the correct order**: When using CBC mode during encryption, e.g., incorrectly creating the MAC before encrypting the data instead of after, to ensure the authenticity and integrity of the encrypted data. +- **Using raw hash constructions where a MAC is required**: For example, computing SHA-256(secret || data) or SHA-256(data || secret) instead of using HMAC, making the scheme vulnerable to length extension and structural attacks. ## Mitigations @@ -61,3 +62,4 @@ Deprecated or risky HMAC implementations like HMAC-MD5 or HMAC-SHA1 are vulnerab - **Do not use deprecated HMAC implementations**: Deprecated HMAC implementations could contain errors that allow for collision attacks. Therefore, only use recommended libraries and functions. - **Do not use non-cryptographically secure algorithms**: Algorithms like e.g. CRC‑32 are not meant to be used for cryptographic purposes. - **Use the complete HMAC digest and avoid truncation**: When possible, always use the complete HMAC digest. When truncating is necessary, never make it shorter than 128 bits. +- **Use HMAC instead of raw hash constructs to detect tampering**: Don't roll your own hash constructs; instead, follow recommended approaches for how to implement HMAC. From 85f9e01462cbea7d5c1caa85c70a4965cf715ae1 Mon Sep 17 00:00:00 2001 From: Uncle Joe <1244005+sydseter@users.noreply.github.com> Date: Tue, 25 Nov 2025 11:05:51 +0100 Subject: [PATCH 16/17] Update MASWE-0024.md --- weaknesses/MASVS-CRYPTO/MASWE-0024.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/weaknesses/MASVS-CRYPTO/MASWE-0024.md b/weaknesses/MASVS-CRYPTO/MASWE-0024.md index ec93930..8454187 100644 --- a/weaknesses/MASVS-CRYPTO/MASWE-0024.md +++ b/weaknesses/MASVS-CRYPTO/MASWE-0024.md @@ -52,7 +52,7 @@ Deprecated or risky HMAC implementations like HMAC-MD5 or HMAC-SHA1 are vulnerab - **Using a non-cryptographically secure algorithm**: Using CRC‑32, which is not meant to be used for cryptographic purposes. - **Truncating the HMAC digest too much**: Truncating the final HMAC digest makes it shorter than 128 bits. - **Not applying the MAC in the correct order**: When using CBC mode during encryption, e.g., incorrectly creating the MAC before encrypting the data instead of after, to ensure the authenticity and integrity of the encrypted data. -- **Using raw hash constructions where a MAC is required**: For example, computing SHA-256(secret || data) or SHA-256(data || secret) instead of using HMAC, making the scheme vulnerable to length extension and structural attacks. +- **Using raw hash constructs where a MAC is required**: For example, computing SHA-256(secret || data) or SHA-256(data || secret) instead of using HMAC, making the scheme vulnerable to length extension and structural attacks. ## Mitigations From 84eb0877122369492de08743b1ce9093df83273c Mon Sep 17 00:00:00 2001 From: Uncle Joe <1244005+sydseter@users.noreply.github.com> Date: Tue, 25 Nov 2025 11:13:23 +0100 Subject: [PATCH 17/17] Refine HMAC usage explanation in MASWE-0024 Clarified language regarding HMAC usage with low-entropy inputs and improved readability. --- weaknesses/MASVS-CRYPTO/MASWE-0024.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/weaknesses/MASVS-CRYPTO/MASWE-0024.md b/weaknesses/MASVS-CRYPTO/MASWE-0024.md index 8454187..e0b10d6 100644 --- a/weaknesses/MASVS-CRYPTO/MASWE-0024.md +++ b/weaknesses/MASVS-CRYPTO/MASWE-0024.md @@ -34,7 +34,7 @@ status: placeholder ## Overview Improper use of a MAC, e.g., not using proper nonces or timestamps, may allow MAC forgeries, making it possible to compromise the authenticity and integrity of the data. -Another common issue is using an HMAC with any type of general-purpose hashing algorithm (like MD5, SHA-1, SHA-2, or even SHA-3) on low-entropy input, such as user-supplied passwords, PINs, or other user-controlled predictors. HMACs are not designed for use with low-entropy inputs or low-entropy keys. Using HMACs in this way will result in "weak" message digests that can easily be exploited. +Another common issue is using an HMAC with a general-purpose hashing algorithm on low-entropy input, such as user-supplied passwords, PINs, or other user-controlled inputs. HMACs are not designed for use with low-entropy inputs or low-entropy keys. Using HMACs in this way results in "weak" message digests that can be easily exploited. Deprecated or risky HMAC implementations like HMAC-MD5 or HMAC-SHA1 are vulnerable to collision attacks that would compromise the authenticity and integrity of the data. Collision attacks can also be made possible through truncating the HMAC digest. If truncating is necessary for interoperability, never truncate the digest below 128 bits and use the full HMAC whenever possible. Finally, never create checksums using non-cryptographically secure algorithms like CRC‑32, which are not meant for cryptographic purposes. ## Impact