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. zz 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+. zz 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
