Which of the following is least effective at deterring man-in-the-middle attacks?
A.
encrypting network traffic
B.
issuing single-use access tokens
C.
mutual authentication
D.
biometric authentication
E.
using time stamps or transaction IDs to detect and discard replay attempts
Explanation:
In order to avoid man-in-the-middle attacks a security framework must have
capabilities
such as:
* Logging in users without the need to type passwords or PINs (not D)
* Dynamically challenging the user for different information, e.g., asking a random
question for which only the user will know the answer
* Encrypting and signing transmissions from the client to the back end server (not A)
* Detecting replays using embedded transaction ids or timestamps (not E)
* Presenting proof to the user that the site they are visiting is authentic
Propagating a single proof object, or assertion, can be susceptible to
man-in-the-middle attacks and replay attacks. If a rogue entity observes an assertion, it
could reuse that assertion for illegitimate requests. Possible solutions include:
* (notB) Invalidate the assertion after every request. In the case of chained SOA Services,
service providers must verify each assertion they receives with the authority. The
authority can invalidate assertions in its internal cache. Any future verifications
with the same assertion would fail. SOA Service providers would need to obtain a
new assertion in order to make subsequent service requests. This solves both types
of problems mentioned above.
* (notE) Reduce and enforce the assertion’s time to live attribute. This would narrow the
window of opportunity to reuse an assertion. The assertion would have to be
captured and reused in a short period of time (programmatically vs. manually).
While this limits the potential for man-in-the-middle attacks, it’s not as effective
for replay attacks
* Require the signature of a trusted service consumer (client application) in addition
to the signed assertion. The caller’s signature should cover the assertion to bind it
to the message. If all service consumers are required to sign their request
messages, then service providers can be shielded from rogue clients, thereby
preventing man-in-the-middle attacks.This solution would need to be enhanced to solve replay attacks. One option is to
include a unique request id, timestamp, or sequence number in the request. The target
resource could maintain a cache of ids and refuse duplicate requests. A common
request id service could be created to issue unique request ids and validate all requests
that are received within the security domain
Reference: Oracle Reference Architecture,Security, Release 3.1