Regardless of the paradigm used, the password or the keys are information that must be agreed upon in advance between the parties. The robustness of the mechanism lies in the confidentiality of this information, which must be kept secret through a joint effort of the participants.
For this reason, it is recommended that users remember their credentials and not write their keys or password in a medium where a hacker can read them.
The secrecy of the username is considered not decisive for security purposes. Although they are vulnerable to possible replay attacks, many authentication procedures today continue to be based on the username/password paradigm. Such a paradigm is typically used only to authenticate the client. A hacker who intends to take over from the client and access an internet service has to obtain the username/password pair.
The simplest technique for deriving the password is to intercept the information transmitted over the network using a software protocol analyzer (packet sniffer). Instead of the plaintext password, if a hash produced by the requestor is transmitted over the network using a non-variable binary sequence as input, the authentication scheme is equally attackable.
A second chance for the hacker is to try to obtain the credentials list stored on the server directly. To complicate this form of attack, each server will have to store the password in cryptographic form rather than in cleartext. This solution does not completely eliminate the vulnerabilities related to the storage of passwords on unprotected media.
An attacker who has come into possession of the digest can still try to trace the password that generated it by proceeding with a brute force attack or an attack based on a predefined vocabulary.
Recently, other, more effective techniques have also become popular for forcing databases containing password hashes. The best-known technique is based on the use of rainbow tables and the general principle of the “time for memory” exchange.
This principle involves precomputing every possible input of a hash function and storing the result in memory. Once the attacker has the hashes of the passwords, they can easily derive a password (if these are among the inputs used for precomputation) simply by searching the stored table.
The rainbow tables are special tables that allow you to reduce memory space, providing only the storage of outputs obtained at the end of a chain of hash operations (starting from a given input).
To derive a password using a rainbow table, it is not sufficient to extract the input associated with the retrieved digest from the table. On the other hand, it is necessary to reconstruct the entire sequence of steps of the chain of hash operations of interest to determine the password sought.
In practice, this is an acceptable compromise. The space necessary for storing the precomputation tables is reduced, knowing that, for the precise identification of a password, it will then be necessary to re-perform some of the calculations carried out to construct the tables themselves (chain reconstruction). In his search for credentials, a hacker can finally try to access any credentials stored on the client, where the information can be protected in a milder manner than what happens on the server.
The information stored on the client is, in fact, very often stored in cleartext rather than encoded through a cryptographic function (the use of a client-side digest function is obviously not feasible as it cannot be reversed).
To avoid the possibility of information stored with the client being stolen, the ideal solution is not to store this information on physical media attached to the client at all. With this in mind, many applications expect the password to be entered manually by the user as a response to a prompt from the server.
Alternative Solutions to Credential Stuffing
To simplify this task, the user usually chooses passwords that are easy to remember and can be typed in without making mistakes. This makes it possible to remember the password mentally, preventing the user from writing it down on a physical medium that an attacker can illegally acquire. On the other hand, the use of predictable passwords (common or very short words) makes it easier for hackers to crack the password by suggesting a limited set of more likely terms (such as terms found in the standard vocabulary).
To avoid choosing too trivial a password, let a smartcard or token produce them rather than the user’s imagination. In this case, the hardware device responsible for generating and storing the credentials for accessing the service must be available to the user when the authentication procedure is performed.
However, in the event of the loss of the physical media in which the credentials are stored, anyone who possesses them can try to replace the legitimate user. Many authentication schemes based on smartcards or tokens provide for a hybrid procedure.
This solution foresees that a secret component P must be concatenated to the result shown on the hardware device display. This P must be manually typed by the user when receiving the server prompt. It is still advisable to change the credentials used to access the service regularly to minimize the chances of a hacker’s success. The use of a password with limited time validity introduces a maximum time within which a hacker must intercept/extract the password and use it.
After this time window, the password is no longer accepted as a credential for accessing the service. To optimize this general principle, it is possible to implement a scheme within which the validity of each password exchanged between participants is limited to the current session only.
One Time Password
With the use of a one time password (OTP), a hacker who intercepts the username and password cannot use this pair in any way. The authentication phase, just successfully completed by the legitimate user, effectively renders the password used no longer valid. Such a scheme inhibits any possible replay attack. A scheme in which passwords are valid for only one authentication procedure is generally known as an OTP scheme.
An OTP scheme can be considered a particular case of challenge/response paradigm. It can be implemented, if necessary, without using symmetric or asymmetric cryptographic algorithms, with an iterated use of digest functions.
Although many internet services only provide for client authentication, applications are increasingly spreading for which the client is required to verify the server credentials before using the service (an example of this is represented by e-commerce where it is good to know with whom you are dealing, on the server-side, before sending confidential data to complete an online purchase).
To authenticate both participants, the server must also send its credentials after client authentication is complete. If an asymmetric cryptographic algorithm and a paradigm such as a challenge/response one are used, the general scheme becomes the following:
- The client sends its username.
- The server responds with a first challenge R.
- The client returns an encrypted copy of R1 (using a shared key KAB ).
- The client sends a second challenge R2.
- The server returns an encoded copy of R2 (using a shared key KAB).
The previous authentication scheme is not optimized. The number of steps required to resolve the authentication procedure can be reduced to 3 if the client is expected to be the first to send a challenge.
In that case, you can rearrange things by transforming the procedure as follows:
- The client sends his username and a first challenge R1.
- The server returns an encrypted copy of R1 (using a shared key KAB) and the second challenge R2.
- The client returns an encoded copy of R2 (using a shared key KAB).
This “reduced” scheme is subject to a peculiar form of attack, known as “data reflection attack”. A hacker intending to replace the client sends the server the first request for access to the service with an R1 challenge.
According to the previous scheme, it receives a response from the server containing the coded version of R1 and the second challenge, R2. The attacker, not knowing the KAB key shared between client and server, cannot currently respond to the challenge. However, they can send the server a second request for access to the service, this time specifying R2 as their own challenge.
The server responds to the challenge and returns to the hacker exactly the data they needed to complete the first authentication procedure. At this point, it is easy for a hacker to transmit what was previously received from the server, illegally gaining access to the service. This form of attack is not viable if the first challenge to be solved is the client’s responsibility.
To prevent the data reflection attack, however, it is not necessary to go back to using the more complex scheme. Subject to the introduction of appropriate changes, the mutual authentication procedure can be maintained in just 3 steps.
The first possible solution is to use different keys for the encryption operations performed by the client and the server. By maintaining symmetric algorithms, it is sufficient for the participants to share two distinct common keys:
- A server write key
- A client write key
One participant’s write key is used to decrypt the message by the other participant.
Asymmetric Encryption
Another way to solve the attack is to use asymmetric encryption. In this case, each participant is asked to encrypt the challenge received with their own private key. Verification of the response is done by decrypting the message with the corresponding public key. Using this approach, a hacker cannot obtain the answer to the proposed challenge from the server for free.
In fact, by proposing the server’s challenge to the same server, it encrypts it with its own private key, producing a completely different result from what a legitimate client would do (using the client’s private key). If this result is sent by the hacker to the server, the authentication phase is considered unsuccessful, and the incident can be reported to an automatic system for detecting intrusion attempts.
The use of asymmetric algorithms or several common keys in the context of the asymmetric algorithm can sometimes be considered an unsustainable solution. In this case, it is still possible to avoid a data reflection attack by carefully checking the proposed challenges.
The encoding of a challenge must be carried out by the server if and only if the server itself has not previously produced this challenge. A server that keeps historical information regarding the previous challenges issued can notice when its internal random number generator produces new challenges identical to challenges already circulated or when the challenges submitted by the clients are identical to challenges already produced by the server.
Since the possibility that two random number generators generate two same challenges is very low, using sufficiently long challenges, the server must reject every challenge sent by the customer, which is not an absolute novelty. In this way, a hacker cannot terminate their data reflection attack even if the participants use a single shared common key.
And there we have it. We have discussed in great detail the different user authentication and access measures and how they help avoid credential stuffing.
I hope you found this article helpful.
