Note: This is a previous year comprehensive solutions for your reference, feel free to provide solutions by navigating Submit Question/Answer tab in case you have latest solutions.
1) Jira's password is made of up 6 alphanumeric characters only. One password attempt takes 1 millisecond, What is the time to crack it in days?
i) If password is case-sensitive.
ii) If password is case- insensitive.
i) If password is case-sensitive.
ii) If password is case- insensitive.
Answer:
i) Case sensitive
total chars = 26 + 26 + 10 = 62
possible combinations = 62 ^ 6 passwords
total time taken = 62 ^ 6 . 1 ms
approx. 62.62 =~ 3600 sec = 1 hour
Total time taken = 62. 62. 62. 62 / 1000 hours
=~ 360. 36 hours = 360.36/24 days
=~ 360.3/2= 180.3 = 540 days
Note: 62^4/1000/24 =~ 615 days
So an approx. answer between 520 to 620 days is good enough.
i) Case sensitive
total chars = 26 + 26 + 10 = 62
possible combinations = 62 ^ 6 passwords
total time taken = 62 ^ 6 . 1 ms
approx. 62.62 =~ 3600 sec = 1 hour
Total time taken = 62. 62. 62. 62 / 1000 hours
=~ 360. 36 hours = 360.36/24 days
=~ 360.3/2= 180.3 = 540 days
Note: 62^4/1000/24 =~ 615 days
So an approx. answer between 520 to 620 days is good enough.
ii) Case insensitive
total chars = 26 + 10 = 36
possible combinations = 36 ^ 6 passwords
total time taken = 36 ^ 6 . 1 ms
= 36.36.36./ 1000 . 36 ^3
=~ 36. 36 ^ 3 seconds
= 36. 36. 36. 36 / 3600 hours
= 466 hours
=~ 19 days
So an approx. answer between 18 to 20 days is good enough.
2) What is a self-signed SSL certificate ? Detail on the security perspective when a website is using a self-signed SSL certificate.
Answer:
A certificate not-signed by a Publicly trusted CA, but signed by a locally setup CA server is a self-signed certificate. Any entity/website/server using a self-signed SSL certificate cannot be trusted and very commonly used in phising attacks. I can setup a server to act as gmail.com fradulently by creating a self-signed certificate for www.gmail.com and deploying it in the server.
Most standard browsers – Firefox, Google Chrome, Safari, etc. throw errors when trying to browse to websites having self-signed certificates.
3) How to avoid man-in-the-middle attack in SSH sessions? Show passwordless SSH logins at work.
Answer:
Man-in-the-middle attack is at-work when a client C logs in to a server M thinking it is server S and the client C is unable to detect it. In this case, the server M has successfully duped the client C and has forged a man-in-the-middle attack. So it can be a passive two-way data forwarder between client C and the actual server S, or an active data-mangler.
Every host server in SSH have their public keys sent to the client in the Key Exchange., which gets stored in client’s .ssh/known_hosts file. So the next time, client connects to the host, the server sent public key is matched with the client’s .ssh/known_hosts file and if there is a mismatch, SSH does not connect. So this SSH behavior effectively thwarts a middle server M trying to pose as actual server S.
Every host server in SSH have their public keys sent to the client in the Key Exchange., which gets stored in client’s .ssh/known_hosts file. So the next time, client connects to the host, the server sent public key is matched with the client’s .ssh/known_hosts file and if there is a mismatch, SSH does not connect. So this SSH behavior effectively thwarts a middle server M trying to pose as actual server S.
Password less SSH logins happen via public keys.
Consider Client C connecting to Server S. In server S side, in file .ssh/authorized_keys, there should be entry containing client C’s public key. Then the server S will use it to exchange - encrypting/signing initial key exchange material with the client C. Because of the property that any data encrypted with public key can only be decrypted using the matching private key, this mechanism automatically authenticates the client C as only client C holds the private key. Client’s private key file are usually stored in file .ssh/id_rsa or .ssh/id_dsa depending on the public key algorithm chosen.
Consider Client C connecting to Server S. In server S side, in file .ssh/authorized_keys, there should be entry containing client C’s public key. Then the server S will use it to exchange - encrypting/signing initial key exchange material with the client C. Because of the property that any data encrypted with public key can only be decrypted using the matching private key, this mechanism automatically authenticates the client C as only client C holds the private key. Client’s private key file are usually stored in file .ssh/id_rsa or .ssh/id_dsa depending on the public key algorithm chosen.