IT-549 Module 3: Scenario Assignment
Scenario Assignment: Hashing and Authentication Threats
Scenario 1: Alice sends a password, and Bob compares it against a database of
passwords.
There are several threats in this scenario such as a man in the middle attack can occur
when an eavesdropper or intruder intercepts message being sent from Alice to Bob, with an
unencrypted password, giving the intruder access to Alice’s account or information message,
and also lock Alice out of the conversation and misrepresent themselves to Bob as Alice.
Brute force attack or dictionary attack is also possible in this scenario, in which all possible
password variation or common passwords are tried to gain unauthorized access to the user
account. In this scenario also, an adversary can obtain a copy of password database and use
the information to also log into Alice’s or any user connected to that password database. g The
best solution to this problem would be to encrypt the password with a hash or use a salted
password, which will prevent against eavesdropping and also storing the hash values in the
database instead of a plaintext, which protects against database disclosure (Conklin and White,
2015).
Scenario 2: Alice sends a password, and Bob hashes it and compares it against a
database of hashed passwords.
This scenario is open to a man-in-the-middle attack and a replay attack, in which an
intruder intercepts the hashed password. Even though the password is protected, the hash
value is still exposed, which allows an intruder to replay the encrypted hash password to the
server (Goldschmidt, 2015). Since the server only stored the hash value, the intruder does not
need to decrypt the password but only needs to replay the hash value to the server to gain
access to that server. In this situation, the database has been compromised and a remote
authentication has been enabled without having to guess the original password (Defuse
Security, 2016). This scenario is also vulnerable to a rainbow table attack, which uses a
precomputed table that contains a hash function’s input and corresponding outputs, used to
exploit or access a server or network as an authenticated user (Haughn, 2015).To prevent this
situation, the database of hashed password must be protected. The best way to prevent replay
attacks is with encryption, cryptographic authentication and timestamps (Conklin and White,
2015). This increases the complexity of the salted hash and makes the rainbow table
precomputing process irreplicable between systems (Conklin and White, 2015).
Scenario 3: Alice computes the hash of a password and uses it as secret key in
challenge/response protocol.
Generally challenge/response protocols are vulnerable because a shared key is needed,
which requires the medium of exchanging the shared secret key must be protected and the
server need to store the plain password or an equivalent hash value. An attacker can intercept
this exchange medium and gain control of the key or even the hashed equivalent. If an
intruder gets hold of this hash value, it makes it as sensitive as the password itself, since an
intruder can actually use the hash to gain access. Another vulnerability of the challenge
response authentication is that it is open to reflection attacks, especially when the same
protocol is used both directions. An attacker can initiate a connection to the target (Alice),
which attempts to authenticate the attacker by sending a challenge. The attacker can then
initiate a second connection in which the same challenge is sent to the target (Alice) and Alice
responds to the challenge. The attacker can now send back that response on the original
connection and in a situation where there was a poorly designed protocol, the target can
accept this response as valid giving access to the attacker. The best solution in this scenario is
using a Salted Challenge Response Authentication Mechanism, which uses a salt to conceal
the has value of the password, a nonce and an iteration count, which mentions the amount of
time a cryptographic function is applied to the salt and password to generate it output
(Fiazachi, 2014). When used properly, they protect against password interception, database
attacks and stores the secret data in a secure format (Isode, n.d.).
Scenario 4: Alice computes the hash of a password and sends it to Bob, who hashes it
and compares it against a database of doubly-hashed passwords.
The problem with double hashing is that contrary to common misconception that
double hashing is supposed to be more secure, it creates interoperability problems and result
in multi-collision of iterated hash functions (Halunen, 2012). Multi-collision occurs when
there is a concatenation of different hash functions, which makes the final hash value even
much weaker than standard or well tested algorithms because more than one string other than
the user’s password can have the same hash value (Halunen, 2012). To prevent this collision
problem of iterated hash function, it better to use a standard hash, which has been well tested
to be collision resistant in conjunction with Salt, which prevents against lookup or rainbow
tables and also prevents the hash value from being attacked.
References
Conklin, A. & White, G. (2015). CompTIA Security+. g All in One Exam Guide, Fourth Ed.
San Francisco: McGraw Hill.
Defuse Security, (2016). Salted Password Hashing - Doing it Right. Retrieved from
https://crackstation.net/hashing-security.htm
Fizachi, D. (2014). Salted Challenge Response Authentication Mechanism (SCRAM).
Retrieved
From http://www.codeproject.com/Articles/698219/Salted-Challenge-Response-
Authentication-Mechanism
Goldschmidt, A. (2016). Replay Attack Vulnerabilities and Mitigation Strategies. Retrieved
from
http://www.cs.tufts.edu/comp/116/archive/fall2015/agoldschmidt.pdf
Haughn, M. (2015). Rainbow Table. Retrieved from
http://whatis.techtarget.com/definition/rainbow-table
Halunen, K. (2012). Hash Function Security: Cryptanalysis of the very Smooth Hash and
Multi-
collisons in Generalized Iterated Hash Functions. Retrieved from
http://jultika.oulu.fi/files/isbn9789514299667.pdf.
Isode. (n.d.). SCRAM: A Protocol for Password Authentication. Retrieved from
http://www.isode.com/whitepapers/scram.html
