TiagoRG
/
sio-2425
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

3.5.3 topic added

This commit is contained in:
RubenCGomes 2024-12-29 00:06:06 +00:00
parent 8647008205
commit 1cf6dbebbd
No known key found for this signature in database
1 changed files with 21 additions and 1 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

22
delivery3/analysis.adoc
View File

@ -194,7 +194,27 @@ The application uses that exact implementation, using session tokens instead of
===== 3.5.3 ===== 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 ==== Federated Re-authentication