Skip to content

Latest commit

 

History

History
171 lines (120 loc) · 7.86 KB

README.md

File metadata and controls

171 lines (120 loc) · 7.86 KB
Raw

Computer Security - Work 2

Computer Security project second phase of group 03 from LEIC51D class.

The Portuguese version of this document is available here.

Authors

Professor: Eng. José Simão

@ISEL
Bachelor in Computer Science and Computer Engineering
Computer Security - LEIC51D - Group 03
Winter Semester of 2022/2023

Exercises

Exercise 1

a) The authenticity of messages in the record protocol is guaranteed through the use of a MAC (Message Authentication Code), which is calculated over the message and its respective shared secret. This MAC is then sent along with the message, so that the receiver can verify its authenticity.

b) The detection of malicious insertion or alteration of messages is done through the Finished message that is sent at the end of the handshake, indicating that the handshake was successfully concluded on the client. This message contains a MAC that is calculated over the shared secret and the respective handshake hash. The server then calculates its own MAC and compares it with the received MAC, verifying if the handshake was successfully concluded and that there were no malicious alterations.

c) The use of public and private keys to establish the pre-master secret does not guarantee the perfect forward security property, because the pre-master secret generated by the client is shared with the server. If an attacker finds the server's private key, he will be able to decrypt the pre-master secret and, consequently, decrypt all messages exchanged between the client and the server.

Exercise 2

The programming error in question is a vulnerability in the authentication system, since the attacker can perform a dictionary attack to discover the password that, together with the salt, generates the hash associated with the user. As the attacker has access to the salt, he can generate all possible hashes for all possible passwords, without interacting with the authentication interface, and compare it with the exposed hash. If the generated hash is equal to the exposed hash, the attacker can then use the corresponding password to authenticate to the server, using only one attempt at the authentication interface.

Exercise 3

a) As the structure of the cookie is known and is composed of the user identifier and its hash, if the hash function is not authenticated (e.g. SHA-256), the attacker can generate the cookie and pass himself off as the user.

b) To avoid this attack, the cookie must be generated on the server with an authenticated hash function (HMAC), so that the attacker cannot generate a valid cookie, since he does not have access to the symmetric key that is stored on the server.

Exercise 4

a) The value indicated in the scope represents the resources to which the client wants to have access, these permissions are provided by the resource owner through the authorization server. As the client is the one who decides which permissions he wants to have access, he is the one who determines the value of the scope.

b) The client and the authorization server communicate indirectly through the resource owner's browser when the resource owner does not have an active session on the authorization server. In this case, the client redirects the resource owner's browser to the authorization server, which asks the resource owner to authenticate. After authentication, the authorization server redirects the resource owner's browser to the client, which receives the access_token and the id_token.

c) The access_token is a token that allows the client to make requests to the resource server. This token is generated by the authorization server and sent to the client. An id_token is a token that contains information about the user, being sent to the client after the authentication process. This token has the format of a JSON Web Token (JWT), and only exists in the OpenID Connect protocol.

Exercise 5

a) The RBAC family of models contributes to the implementation of this principle, since with the use of these models, it is possible to limit permissions from the role mechanism, so that a user only has the permissions necessary to perform their tasks. The least privilege principle indicates that a user should only have the permissions necessary to perform their tasks, and not more than that. This principle is important to ensure that a user does not have access to information that is not necessary to them, and that they cannot access resources that are not permitted to them. If it is found that a role has more permissions than necessary, a new role should be created with only the necessary permissions, and assign this new role to the user.

b) The user u2 will not be able to access the resource R, since the role of the user u2 is r2, which has the permissions pa and pb, inherited from the roles r0 and r1, respectively. As the role r2 does not inherit the permission pc from r4, the user u2 will not be able to access the resource R.

Exercise 6

a)

The HTTPS server implemented in exercise 6 is in the file https.server.js.

To run the server, the following configurations were necessary:

  1. Make the appropriate configuration of the hosts file of the operating system, so that the address www.secure-server.edu is resolved to localhost;

  2. Generate PEM files for the private key and server certificate, using the openssl command, so that the server can be executed successfully, without client authentication:

     openssl pkcs12 -in secure-server.pfx -nokeys -out certificate.pem -password pass: # Generate certificate
 openssl pkcs12 -in secure-server.pfx -nocerts -out privatekey.pem --nodes -password pass: # Generate unencrypted private key (--nodes)

  3. Install the certificates necessary for the HTTPS server:

    • CA1-int.cer and CA2-int.cer in the Intermediate Certification Authorities;
    • CA1.cer and CA2.cer in the Trusted Root Certification Authorities.

  4. Generate the CA2.pem file that contains the certificate of the root certificate authority CA2, used to validate the client certificate:

     openssl x509 -inform der -in CA2.cer -out CA2.pem

To establish the connection through the browser with the client authentication of Alice_2, it was necessary:

  1. Install the certificates:
    • Alice_2.pfx in Personal;
    • CA1-int.cer and CA2-int.cer in the Intermediate Certification Authorities;
    • CA1.cer and CA2.cer in the Trusted Root Certification Authorities.

b)

To establish the connection between the implemented client, it was necessary to generate the truststore.jks truststore with the certificate of the root certificate authority CA2 and the intermediate CA2-int, used to validate the server certificate:

keytool -importcert -file "CA2.cer" -keystore truststore.jks -alias "CA2"
keytool -importcert -file "CA2-int.cer" -keystore truststore.jks -alias "CA2-int"

This truststore is then placed in the javax.net.ssl.trustStore system property.

Exercise 7

The exercise 7 was implemented in two different directories, client and server.

Our access policy model was implemented according to the RBAC1 model, containing the following roles:

  • free: user can only see tasks;
  • premium: user can see and edit tasks;
  • admin: user can see and edit tasks.

The role free has a read permission on the resource tasks. The role premium inherits the permissions of the role free, and adds a write permission on the resource tasks. The role admin inherits the permissions of the role premium.

To run the server, it is necessary to run the command npm start in the server directory.