From 1cf6dbebbd3c6f887dac8e8fdfe9d066ace43b71 Mon Sep 17 00:00:00 2001 From: RubenCGomes Date: Sun, 29 Dec 2024 00:06:06 +0000 Subject: [PATCH] 3.5.3 topic added --- delivery3/analysis.adoc | 22 +++++++++++++++++++++- 1 file changed, 21 insertions(+), 1 deletion(-) diff --git a/delivery3/analysis.adoc b/delivery3/analysis.adoc index 7506b23..08ce2d3 100644 --- a/delivery3/analysis.adoc +++ b/delivery3/analysis.adoc @@ -194,7 +194,27 @@ The application uses that exact implementation, using session tokens instead of ===== 3.5.3 -TBD +Since this topic involves a few different types of attacks, it's best to address them individually: + +====== Digital Signatures and Replay +These attacks could be tackled with the use of JWT (JSON Web Tokens). They support a `exp` field, that indicate the expiry date of said packet (protects against Replay attacks). Expiry time could be adjusted dynamically according to client-server ping. + +JWT also supports signatures, so with a given secret key, the server can verify the integrity of the token. The signature is calculated using the header and payload of the token (with the content of the token being base64 encoded). + +====== Tampering +With the support of signatures, the server can verify the integrity of the token, and if it was tampered with, the signature would not match the content of the token. + +Another added layer of security could be the use of a counter, that is incremented with each request, where the server verifies if the counter is correct, and vice-versa. + +====== Null Cipher +The cipher python package used in the project, `cryptohazmat`, uses AES-CFB, that avoids null ciphers. Of course, any failure within the package (or any other package) due to an update or a bug could eventually lead to a null cipher attack. + +====== Key Substitution +Since it is being used a Diffie-Hellman key exchange, the key is never sent over the network, the server and client end up with the same key, so there is no key to be substituted. It is also not possible to substitute a key, that would require re-authentication. + +====== Encryption +The current implementation does not encrypt the session token, which could be a vulnerability. This could be implemented by encrypting the session token with a symmetric key (and use a strong algorithm, like AES-256), and then decrypting it on the server side. This would protect the token from being read by an attacker, even if they manage to intercept it. + ==== Federated Re-authentication