Clarifying Cryptographic Language (e.g. "weak") in MASTG-TEST-0210 & MASTG-TEST-0211

[cpholguera]

Discussed in #3191

^{Originally posted by sydseter March 5, 2025}
Hi, first of all, great work porting from MASTG 1.7 to MASTG 2.0. I would like to raise a discussion around the language and tests related to MASVS-CRYPTO.

When defining tests concerning cryptographic hashing and encryption it may be good to have a look at the work that has been done by ASVS since most of it should be applicable within mobile development as well. See:

E.g: MASTG-TEST-0211: https://github.com/OWASP/ASVS/blob/master/5.0/en/0x14-V6-Cryptography.md#v66-hashing-and-hash-based-functions
E.g: MASTG-TEST-0210: https://github.com/OWASP/ASVS/blob/master/5.0/en/0x14-V6-Cryptography.md#v65-encryption-algorithms

I noticed that the language used terms that is hard to define (e.g: weak and hashing operations). A weak hashing algorithm like MD5 or SHA-1 may be perfectly fine depending on what it is used for. I think it may be good, for readability, to be more specific as to what hashing operations we are referring to and also to say something about what we mean with "weak". Perhaps "weak" is not the right word. Perhaps, in stead, we should use "recommended" or "approved"?

I am also thinking that there is a lot that may make an algorithm “weak”. E.g: The way IV, salt, padding, etc are used. Should these be separate tests, or should they be part of MASTG-TEST-0210 and MASTG-TEST-0211?

Only a suggestion. What do you think?

[sydseter]

Regarding the use of “weak” in MASWE I was thinking that we could look to the language used in CWEs. E.g:
While MASWE use “weak”, CWE use the word “Improper” which I believe is better and aligns “properly”, pun not intended, with how these “weaknesses” gets addressed when written about in papers and guidelines. It also works well when talking about recommendations. E.g: Input validation can be improperly implemented according to defined security requirements and recommendations, but not weakly implemented. However, the implementation can be perceived as “weak” because security guidelines and recommendations wasn’t properly followed.
https://cwe.mitre.org/data/definitions/20.html

[sydseter]

It make sense to say that you use a “weak” hash (see: https://cwe.mitre.org/data/definitions/328.html), but when talking about mathematical strength in encryption materials and formulas that have been combined into a cryptographic function, it makes more sense to talk about inadequacies. E.g “ Inadequate Encryption Strength”: https://cwe.mitre.org/data/definitions/326.html
But, in the case where a cryptographic algorithm has been found to have vulnerabilities, then you can also consider it to be “risky” to use and even “broken” (see: https://cwe.mitre.org/data/definitions/327.html).

[aakarshgopishetty]

Hi! I'd love to contribute to this issue. Based on the discussion, I will review the current terminology in MASTG-TEST-0210 & MASTG-TEST-0211 and propose improved language aligning with CWEs and ASVS standards. I'll ensure terms like "weak" are replaced with more precise definitions such as "improper," "inadequate," or "risky," depending on the context.

I'll draft a PR soon. Let me know if there are any specific areas you'd like me to focus on!

[sydseter]

@aakarshgopishetty There is already a pr open

[cpholguera]

@aakarshgopishetty this was already assigned to @sydseter

You should be able to see the assignees on the top right area of the issues.