Fixes OWASP/mastg#2589 [MASWE-0025] Weak Signature#4
Fixes OWASP/mastg#2589 [MASWE-0025] Weak Signature#4sydseter wants to merge 19 commits intoOWASP:mainfrom
Conversation
Co-authored-by: Carlos Holguera <perezholguera@gmail.com>
Co-authored-by: Carlos Holguera <perezholguera@gmail.com>
Co-authored-by: Carlos Holguera <perezholguera@gmail.com>
Co-authored-by: Carlos Holguera <perezholguera@gmail.com>
| - **Loss of Integrity and authenticity**: Signature forgery may allow the attacker to compromise the integrity and authenticity of the data by signing the data on behalf of another entity. | ||
| - **Loss of accountability**: Signature forgery allows for plausible deniability and diminishes accountability. |
There was a problem hiding this comment.
- I would add confidentiality: asymmetric algos also ensure it
- I would structure the existing into: integrity (that data being accessed is intact and as expected) and non-repudiation (authenticity - that an action came from a user). Accountability is closer to logging users' actions, indeed, to place.
There was a problem hiding this comment.
- Sure, but let's ensure that MASWE-0025 only applies to weak signatures to ensure integrity, non-repudiation and authenticity.
- A digital signature inherently establishes authenticity (who sent it), integrity (that it hasn't been tampered with), and non-repudiation. Logging is a separate concern. I have divided the section into three.
There was a problem hiding this comment.
@sydseter To me, it conveys the message, and I can understand it. It's rather a matter of project agreement here 😄
@cpholguera how should we approach this? Focus on the technical impact (higher, broader and more pragmatic) like described here or focus on the atomic elements like the Parkerian Hexad.
Maybe CRYPTO can benefit by using the Parkerian Hexad while other groups follow the suggestion in the docs?
I don't have a strong preference on what, I find it more critical that we stay aligned 🙂
There was a problem hiding this comment.
To me, the Parkerian Hexad is more relevant in a larger system. For mobile, keep it simple and practical. We should focus on what is relevant within the context of mobile development and the use of signatures within that context. This way, it's easier for users of the MASWE, developers, to understand what is meant.
Co-authored-by: Dionysis Lorentzos <ddl449@gmail.com>
Co-authored-by: Dionysis Lorentzos <ddl449@gmail.com>
Co-authored-by: Dionysis Lorentzos <ddl449@gmail.com>
Clarified impact statements regarding signature forgery.
Corrected capitalization and punctuation in the impact section.
|
Hi everyone, @Diolor @sydseter For mobile clients that generate signatures, including semantic context such as operation type, timestamp, nonce, and content hash helps ensure Proof of Possession (only the legitimate device, can produce the signature) and non-repudiation (the signature is cryptographically tied to a specific device and operation). I believe this could complement the current Mitigations section by emphasizing secure key binding and contextual signing practices. WDYT ? |
|
@daiane-galvao Absolutely, we do that as well, but, for us at least, it's done through binding the user's session to the private key on sign-in to our IDP. This issue, however, is about mobile application security weaknesses. But there is a need for clear recommendations regarding mobile clients and their role as OAuth clients as well (e.g ASVS 5.0: https://github.com/OWASP/ASVS/blob/master/5.0/en/0x19-V10-OAuth-and-OIDC.md#v102-oauth-client ). There is a MASTG document that talks about JWT tokens, briefly, and I believe your comment is relevant there: First priority now is MASTG 2.0, so even though I personally also feel solutions like Private Key JWT should be considered for mobile application authentication architecture, it won't be prioritized straight away for MASTG. |
|
@daiane-galvao despite that. We do welcome any contributions, so feel free to edit the linked files and keep providing feedback and suggestions for MASWE or MASTG tickets/open PRs. Of course feel free to open discussions or issues. https://mas.owasp.org/contributing/1_How_Can_You_Contribute/ Thank you. |
There was a problem hiding this comment.
Pull Request Overview
This PR converts MASWE-0025 from placeholder status to a fully documented weakness entry. The document now provides comprehensive guidance on improper generation of digital signatures.
Key changes:
- Updated title from "Improper Generation of Cryptographic Signatures" to "Improper Generation of Digital Signatures"
- Changed status from "placeholder" to "new"
- Added complete documentation including Overview, Impact, Modes of Introduction, and Mitigations sections
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com>
Co-authored-by: Carlos Holguera <perezholguera@gmail.com>
Co-authored-by: Carlos Holguera <perezholguera@gmail.com>
Co-authored-by: Carlos Holguera <perezholguera@gmail.com>
Co-authored-by: Carlos Holguera <perezholguera@gmail.com>
Co-authored-by: Carlos Holguera <perezholguera@gmail.com>
|
@Diolor could you please take another look? We added a couple of changes. |
This PR closes #119
Description
See issue for details
[x] I have read the contributing guidelines.
Guidelines for Pull Requests (you can delete this section after reading):