Challenge Response Authentication Mechanism (CRAM) is the most
often used way to authenticate actions. They are a group of
protocols in which one side presents a challenge(to be answered)
and the other side must present a correct answer(to be
checked/validated) to the challenge in order to get
authenticated.
Figure – CRAM activity flow diagram
Two types of questions (Challenge) –
- Static questions, as the name suggests, involve a static
approach to the challenge selection. The user can select his
challenge and authenticate himself. For example, take the use case
of FORGET PASSWORD in email services. A static challenge is the
‘security question’ that you have saved as part of your account
setup. The correct answer to those questions are not expected to
change over time.
- Dynamic questions involve a dynamic approach to the Challenge
selection and authentication. The challenges are selected randomly
presuming that the user will know the valid answer to the challenge
considering the user is the real one.
Ways CRAM is executed –
- CAPTCHA:
- The Completely Automated Public Turing Test to Tell Computers
and Humans Apart. CAPTCHA is used to prevent spam and
auto-registration of new accounts for email or websites.
- SSH (Secure SHell):
- SSH is a cryptographic network protocol for operating network
services securely over an unsecured network.
- Password:
- The password is sent to the server for validation by matching
with the correct password.
- Salted Challenge Response Authentication Mechanism (SCRAM, a
variant of CRAM):
- The challenge is salted with a hash to make sure the password
is used for only one time. The hash is sent to the server for
matching with the hash of the correct password for match and not
the match of the plain text password itself. So, the password is
not revealed preventing the Man-in-the-Middle attack and replay
attacks because the password can be used only once.
- Biometrics:
- The biometric details(retina scan, fingerprint scan) that are
unique are recorded and everytime a user wants to authenticate
himself, he has to present his biometric credentials to the
authenticating system for validation.
Use cases –
- To differentiate between a computer and a human:
- An image (usually difficult to read in plain glance) is
presented to the user and the user would be asked to input by
reading the characters from the image. The input is then matched
with the actual characters to prevent bots from entering the
system.
- In training Machine Learning models:
- An image is pieced and jumbled up and presented to the user for
some kind of verification that a real human user can do. The input
is used for user validation. The answer given by the user is
matched with the answer given by the ML model. The jumbled up image
is the ‘challenge’ and selecting the right pieces is the example.
Commonly seen in Google CAPTCHA authentication.
- For login (authentication) purposes:
- The password input is matched(directly or indirectly) with the
correct password(already stored in the server that you are trying
to access) for matching.
Common attacks on CRAMs –
- Eavesdropping
- Phishing Attacks
- Pharming Attacks
- Man-In-The-Middle Attacks
- DNS Cache Poisoning Attacks
- Trojans Attacks
- Man-In-The-Phone Attacks
- Browser Poisoning Attacks
- Dictionary Attacks
- Brute-Force Attacks
- zero-knowledge password proof
- Reusable password attacks
Limitations –
A fundamental problem with passwords is that passwords are used
repeatedly. When a password is received by the server, the server
cannot determine if the real user is entering the password or
not.
Newer CRAMs also employ cryptography so that the hash of the
passwords are matched and not the plain passwords.
Some examples of cryptographic CRAMs –
- SCRAM – Salted Challenge Response Authentication Mechanism
- CRAM-MD5
Commercial security is a matter of solving the practical
problems of business relationships such as privacy, integrity,
protecting property, or detecting breach of contract. A security
hole is any weakness that increases the risk of violating these
goals. In this real world view of security, a problem does not
dissapear because a designer assumes it away. The invocation or
assumption in a security protocol design of a "trusted third party"
(TTP) or a "trusted computing base" (TCB) controlled by a third
party constitutes the introduction of a security hole into that
design. The security hole will then need to be plugged by other
means.
If the risks and costs of TTP institutional alternatives were
not accounted for in the protocol design, the resulting protocol
will in most cases be too costly or risky to be practical. If the
protocol beats these odds and proves practical, it will only
succeed after extensive effort has gone into plugging the TTP
security hole(s). TTP assumptions cause most of the costs and risks
in a security protocol, and plugging TTP security holes produces
the most benefit and profit.
As a result, we propose a security protocol design methodology
whereby the most risky and expensive part(s) of a security
protocol, the trusted third partie(s), are designed in parallel
with security protocol(s) using those parties. The objectives of
cost and risk minimization are focused on the TTPs rather than the
security protocols themselves, which should be designed to suit the
cost and risk minimized TTPs.