DITA: A Dynamic Image-Based Authentication Protocol for Secure Network Communication Against Replay and Eavesdropping Attacks

Abstract

Tokens are widely used to secure client–server communications in systems based on automatic authentication. These tokens can be vulnerable to hacking, as an attacker can impersonate a real user by eavesdropping on their communications. In this paper, we propose a new authentication mechanism that generates a random token for each authentication. The token consists of confidential data and is encrypted using random coordinates from a securely stored confidential image. The client uses a random session key to encrypt the confidential image, then encrypts the token using randomly selected coordinates by matching ASCII character values with pixel values. The results and analysis demonstrate improved resistance to credential theft, replay attacks, and passive eavesdropping under the stated security assumptions. Even if hackers crack the encrypted token, decryption is difficult because the encryption method relies on values unrelated to the original authentication data. Comparison results also demonstrate efficiency and reliability compared to existing systems, as well as their ability to withstand brute-force attacks, with the entropy of the probability distribution being the best.

1. Introduction

Password-based authentication is the most common method used in various systems and applications to verify user identities [1,2,3,4]. Authentication systems have been developed to provide ease of use and speed in the communication process, so that communication is automatic without manual entry for each communication session by creating a communication token between the two parties [5,6,7,8]. In addition to a set of measures implemented by the system to protect passwords from unauthorized access, such as secure encryption channels or different encryption algorithms to secure their transmission, these tokens may be vulnerable to exploitation if they fall into the hands of an attacker, as they may remain constant until changed [9,10,11]. This allows an attacker to impersonate the user and access the system without the original password, posing a direct threat to data integrity and communication security [12,13].

In response to the drawbacks of manually entering passwords into automated systems, the token-based authentication model has become the most commonly used to maintain session continuity and facilitate smooth communication between devices [14]. These tokens are cryptography tools that represent authenticated sessions enabling systems to verify identity without repeatedly requesting users to provide credentials, thereby supporting the high-speed and automated interaction needed by modern distributed applications [15]. Modern authentication systems support an assortment of token formats, such as JSON Web Tokens (JWTs) in web services and session cookies in web browsers, all aimed at balancing the needs of performance and security guarantees. Nonetheless, the popularization of a token-based authentication method has left a serious security threat: long-term persistent tokens can be used by an attacker who can conduct an attack in the form of interception, theft, or retransmission [6].

Security problems of fixed-token systems are not a secret and are actively abused by real-life attacks. Another efficient method of stealing authentication tokens and impersonating authorized users without acquiring the original credentials is a man-in-the-middle (MitM) attack where attackers intercept between legitimate parties. In systems that lack proper update mechanisms, retransmission attacks, where stolen tokens are resubmitted to gain unauthorized access, are still effective [16]. By stealing tokens in different forms such as using malware, cross-site scripting, or compromised storage, attackers can bypass authentication completely since having a valid token can provide the same access privileges as a legitimate credential [17]. Such weaknesses are compounded when secure means of communication cannot be ensured during initial registration or when computational resources are insufficient to support more complex encryption protocols. Not only do the results of token breaches involve individual account breaches, but they also involve systemic risks, such as data leaks, unauthorized transactions, and collapses of interconnected systems.

To overcome these shortcomings, we propose a new Dynamic Image-Based Authentication (DITA) protocol in this paper. The basic idea is to generate an access token from an image that both the client and server securely store. The client generates a random session key to derive a session-specific coordinate space from the shared image and uses it to encode a session-bound authentication token during each authentication. At the other end, the server receives the coordinates and the key, reconstructs the same coordinate space, and recovers the transmitted token to compare it with the expected token computed from the stored credential hash. No token can be used more than once, and the authentication data is temporary, unique, and non-repeatable using a random key that changes with each request, preventing an attacker from attempting a replay attack. The main contributions of this paper are as follows:

• Preventing the risk of login token theft, as the authentication system relies on replacing static tokens with dynamically generated authentication data.
• The proposed protocol requires a secure channel during the initial registration phase to provision the shared secret image. During subsequent authentication sessions, the protocol does not rely on transport-layer confidentiality to protect credentials because the exchanged packet contains only a one-time authentication proof derived from the shared secret image. Nevertheless, authenticated and integrity-protected communication channels are recommended in practical deployments to protect against active packet modification and channel-level attacks.
• The one-time random token generated by the algorithm provides robustness against token theft, replay, and interception attacks, while maintaining a low computational cost.
• The proposed protocol adapts to changes in the ability to change images continuously and in the algorithms used to encrypt them, preventing probabilistic attacks.

The remainder of this paper is organized as follows. Section 2 provides a brief review of previous work. Section 3 presents the proposed protocol methodology and describes its working mechanism. Section 4 presents the performance evaluation. Section 5 describes the threat model and security assumptions. Section 6 presents the security evaluation of the proposed protocol. Section 7 discusses the limitations of the proposed system. Section 8 outlines future research directions. Finally, Section 9 concludes the paper.

2. Related Work

Cybersecurity research in authentication has evolved through several approaches to develop robust, easy-to-use mechanisms [18,19]. Traditional authentication mechanisms that use usernames and passwords suffer from security vulnerabilities that make them vulnerable to hacking. They can be stolen directly if intercepted in transit, by brute force attacks, or by reusing encrypted passwords via replay attacks, facilitating user identity theft without the knowledge of the server or user. An attacker can continue to access the account for extended periods without being detected.

One is the use of out-of-band validation and the use of visual codes to ensure the integrity of transactions in banking settings where QR codes are used independently per transaction and thereby eliminate phishing and man-in-the-middle attacks over independent mobile channels [20]. Protecting templates and resisting an impersonation attack, encrypted image matching and steganographic visual shares are deployed [21]. Physical Unclonable Functions (PUF) based hardware-grounded solutions are being hardened against machine learning modeling attacks with split learning and tandem neural architectures to deploy IoT and 6G [22].

This section reviews published studies in four main areas relevant to our work: token-based authentication, visual and image-based authentication systems, steganographic protocols and visual challenge response, and challenge-response protocols. We conclude by identifying the research gaps that the DITA protocol aims to address.

2.1. Token-Based Authentication

Token authentication, such as JSON Web Tokens (JWTs), enables automated login without user interaction [23]. The token is generated from client data (username, password), and the server can verify the integrity of the transmitted token under a prior agreement. However, if an attacker intercepts a valid token, it can be reused until it expires. To mitigate the risk, short-lived tokens are used alongside refresh tokens. Token authentication is a method used in many applications, in which the client generates a token that can be reused until it expires. OAuth 2.0 also uses this algorithm and relies heavily on Transport Layer Security (TLS), thereby preventing it from being exposed to theft [24]. OpenID Connect (OIDC) was introduced as an extension to OAuth 2.0. OIDC adds an authentication layer that enables user identity verification via an identification token sent by the identity provider to the client after successful authentication. However, vulnerabilities to replay and spoofing attacks remain [25]. To mitigate the risk of eavesdropping during the authentication process, SAML is used, which provides authentication to a service provider that is accountable across multiple systems, but the replay attack problem persists until the token expires.

In this work, we propose a different approach: Instead of relying on static tokens or only a short expiration period, this system generates session-specific one-time authentication tokens from a shared secret image. This design reduces the need for frequent revocation or rotation and practically prevents token theft, as authentication tokens are only valid once.

2.2. Steganographic Protocols and Visual Challenge Response

Research in steganographic authentication often involves the server sending a challenge, such as an image containing an embedded secret (e.g., a steganographic hidden string), which the user must extract and submit [26,27]. The user must interact with this distorted image to prove ownership of the original. Our work shares the concept of a pre-shared image. Still, it differs fundamentally in that the image is never transmitted, is used only for randomization in each session, and is used to extract coordinates for encoding the tokens.

2.3. Challenge-Response and Cryptographic Protocols

The basic idea of the protocol is that there is an agreement on the encryption key and algorithm (shared secret) between the server and client, in addition to a synchronized counter (challenge) between the two parties that is included in the encryption process to generate a different code with each new authentication process. The result is different from the previous result because the counter cannot be repeated [28,29]. In standard models, such as HMAC-based one-time passwords (HOTP) and time-based one-time passwords (TOTP) used in two-factor authentication (2FA) systems [30,31]. A counter or timestamp is used as the challenge value, and the client calculates a hash of the challenge and shared secret. The FIDO2 protocol also applies the same approach by generating a pair of public and private keys upon user registration, where the data is encrypted with a private key on the client side and the response is verified using the previously stored public key on the server side. This mechanism reduces the risk of impersonation or direct reuse of authentication data and is one of the most successful examples of partial zero-knowledge proof in authentication systems [18]. However, there are several limitations and challenges, including the fact that a fixed shared secret remains a critical vulnerability. Once the data is leaked, an attacker can generate valid verification values. Relying on time- or counter-based challenge generation also makes the system vulnerable to synchronization or replay attacks within the allowed timeframe. Our proposed system is an updated approach to challenge-response protocols where the client-generated random key acts as a challenge, working with the shared secret (image) to generate random tokens that change during each authentication. It shares the same goal as zero-knowledge proofs, but adds the new advantage of not requiring synchronization between the two parties and of encrypting the secret data based on the cipher image coordinates.

2.4. Graphical and Image-Based Authentication Systems

As an alternative to text-based schemes, one possible alternative proposed is graphical authentication, which uses images, shapes, or patterns as a password that are easier to remember or recognize than text, making it more difficult to counter common attacks such as brute force and shoulder surfing [32]. Passpoints and passfaces are examples of systems that require users to remember and click on predefined points or sequences of faces within images [33,34]. Although these systems share a common image, their threat and operational models are quite different. They rely on cognitive recall, which makes them inherently vulnerable and slow. In contrast, the proposed protocol focuses on image encryption to protect the access token, eliminating the need for user interaction to address input security challenges in these systems.

3. Methodology

The proposed system aims to protect the authentication token during the authentication process. The proposed authentication mechanism consists of two phases. In the first phase, both the client and the server securely store the same shared image during registration. During each authentication session, the client generates a fresh random session key $K_s$, which is used solely to encrypt the shared image and produce a session-specific encrypted image. This encrypted image creates a unique coordinate space for the current session and is not intended to protect or encode the user’s credentials directly. In the second phase, after receiving the server-issued nonce $N_s$, the client retrieves its locally stored credential hash (StoredHash), which was generated during registration by securely hashing the user’s username and password. The client then computes the session-bound authentication token $T=H\left(\mathrm{StoredHash}\parallel K_s\parallel N_s\right)$. Rather than transmitting the user’s credentials or the StoredHash itself, the token is represented by randomly selected coordinates from the encrypted image. The client sends only the authentication packet $P=\left\{ID,K_s,V\right\}$, where $V$ denotes the selected coordinates. Upon receiving the packet, the server retrieves the corresponding StoredHash from its own database, reconstructs the encrypted image using the received session key $K_s$, regenerates the expected token, recovers the transmitted token from the received coordinates, and authenticates the client only if both tokens are identical.

Two sessions cannot use the same temporary authentication data because the generated random key produces an encrypted image with variable values, resulting in variable coordinates. Figure 1 illustrates how the proposed authentication system works.

Figure 1. Workflow of the Dynamic Image Token Authentication (DITA) Protocol.

3.1. Registration Phase

The registration phase is highly secure, as the user’s confidential information (username and password) is transmitted. A shared secret image is exchanged and securely stored on both the client and server. The security of the protocol relies on the integrity and confidentiality of this one-time step.

• Step 1: Submit registration information

• Prepare the secret information: The data that the server sends to the client to complete the authentication process. Instead of encoding the plaintext username and password, the client first computes a salted cryptographic hash of the user credentials:

U → S: Hash{UN || PW||salt}

where Hash(⋅) is a memory-hard password-hashing function, and salt is the user-specific random value established during registration. A memory-hard function is used here specifically because StoredHash is derived from the user’s password and must resist offline brute-force attacks if the credential database is ever leaked. The generated StoredHash is securely stored on both the client and server. On the client side, it is assumed to be protected using the secure storage facilities provided by the underlying platform (e.g., TPM, Android Keystore, Apple Secure Enclave/Keychain, or equivalent mechanisms).

• Step 2: Secret Image Generation

• A unique, robust image I is generated with uniformly distributed pixel values. This image is kept secret between the server and the client for a long time (with the possibility of changing it based on requirements and agreement between the two parties). The image requirements are explained below.
• The image must be complex (the randomness of the values relative to their locations in the image is very high) enough to prevent random guessing. Correlations between adjacent pixels in the image are also kept to a minimum, and the histogram must be uniform for all pixel values, as shown in Figure 2.
• High image resolution, defined by its width $\left(\mathrm{W}\right)$ and height $\left(\mathrm{H}\right)$ to provide a vast coordinate space (W × H).
• The image size is identical on both client and server systems to ensure that $\mathrm{IC}\left(\mathrm{x},\mathrm{y}\right)$ = $\mathrm{IS}\left(\mathrm{x},\mathrm{y}\right)$ for all valid coordinates $\left(\mathrm{x},\mathrm{y}\right)$.

Figure 2. Image specifications. (a) Secret image; (b) Secret image histogram. (c) Secret image adjacent pixel correlation.

• Step 3: Image Encryption Algorithm Agreement

The use of modern cryptographically secure algorithms, specifically AES-128 or AES-256, for practical deployment of the proposed protocol [35,36,37]. A key (whose length is determined by the encryption algorithm) is randomly generated by the client and sent to the server during authentication to generate new coordinates for each session. The goal of encryption is not to protect the image content from theft, but rather to create a temporary copy that produces different coordinate patterns for each authentication session. This ensures that even if an attacker intercepts the connection, they cannot replay previous sessions or predict future challenges. Since the original image is securely stored on both the client and server, computational efficiency and low latency take precedence over encryption robustness.

• Step 4: Secure Image Transfer

The image is transferred from the server to the client device over a secure, encrypted connection (e.g., HTTPS) to prevent eavesdropping and is stored on the client device, depending on the application used.

$$\mathrm{S}\to \mathrm{U}: \{\mathrm{ID},\mathrm{I},Enc\}$$

3.2. Authentication Phase—Client Side (Token Generation)

The client prepares the authentication packet to be sent to the server, as shown in Figure 3a. The process is performed as follows.

Figure 3. The encode and decode method, (a) Client Side: Token Generation, (b) Server Side: Token Verification.

Step 1: Request Authentication Challenge: The client initiates an authentication request by sending its identifier (ID) to the server.

Step 2: Receive Server Challenge. Upon receiving the authentication request, the server generates a fresh, cryptographically secure nonce Ns, associates it with the requesting client, stores it temporarily with a short validity period, and sends it to the client.

Step 3: Generate Session Key and Encrypt the Shared Image. The client generates a fresh random session key K_s and encrypts its local copy of the shared image I to produce the session-specific encrypted image I′:

$$\mathrm{Ks}=KeyGen()$$

$${\mathrm{I}}^{\prime }=\mathrm{Enc}\left(\mathrm{Ks},\mathrm{I}\right)$$

Step 4: The client retrieves its previously stored credential hash (StoredHash), which was generated during the registration phase, and computes a session-bound authentication token:

T = Hash(StoredHash∣∣Ks∣∣Ns)

Step 5: Convert the Credential Hash into ASCII Representation: The salted credential hash T is converted into a sequence of ASCII (or hexadecimal) characters.

Let T_ASCII = (a₁, a₂, …, a_n) be this sequence.

For each ASCII value ai in the sequence (in order), the client performs an exhaustive search of the entire encrypted image I′ to find all coordinate pairs where the pixel value equals that ASCII value ai.

For each ai ∈ T_ASCII:CoordsList_i = {(x,y)∣I′[x][y] = ai}

Step 6: Random Selection of Encoding Coordinates: For each character in the authentication token T (represented by TASCII), the client randomly selects one coordinate pair from the corresponding coordinate list to encode that character in the final proof.

For i = 1 to n:

$$\begin{gathered} (x_i^{sel},y_i^{sel})=\mathrm{random}\left({\mathrm{CoordsList}}_i\right) \\ V=\left(\left(x_1^{sel},y_1^{sel}\right),\left(x_2^{sel},y_2^{sel}\right),\dots ,\left(x_i^{sel},y_i^{sel}\right)\right) \end{gathered}$$

Step 7: Prepare Authentication Packet: The client constructs the packet P containing the user identifier, the proof, and the key needed for the server to verify it.

$$\mathrm{P}=\left\{\mathrm{ID},\mathrm{Ks},\mathrm{V}\right\}$$

Step 8: Send token packet: The client sends the packet P over the network to the server.

U → S: {P}

The complete token generation procedure is presented in Algorithm 1.

Algorithm 1 Token Generation

Input: Plain image I of size x × y, User Identifier ID, StoredHash ← H(UN||PW|| salt) // Compute salted credential hash, Ks is a session key used to encrypt the image, and len is the length of the session key, Ns ← nonce received from server.

Output:      Authentication packet P

1:   Ks ← KeyGen(len) 2:   IC′ ← Enc(Ks, IC)          //Encrypt the secret image to produce session-specific image copy 3:   T = H(StoredHash∣∣Ks∣∣Ns) 4:   T_ASCII ← ASCII_Encode(T)      Convert T into a sequence of ASCII values (a1, a2, …, an) 5:   Initialize V ← []             //List to store selected coordinates 6:   For each ai in T_ASCII do 7:   CoordsList_i ← [] 8:   For x from 0 to width(IC′) − 1 9:              For y from 0 to height(IC′) − 1 10:                   If IC′[x][y] == ai then 11:                           CoordsList_i ← CoordsList_i + [(x, y)] 12:            End For 13:            (x_sel, y_sel) ← RandomSelect(CoordsList_i) // Randomly select coordinate 14:            V ← V + [(x_sel, y_sel)] 15:    End For 16:    P ← {ID, Ks, V}        // Construct authentication packet 17: Send(P) to Server      // Transmit packet over the network

3.3. Authentication Phase—Server-Side (Validation)

The server, after receiving the request, decodes the sent packet as shown in Figure 3b, then verifies the recovered authentication token as follows.

Step 1: The server receives packet and extracts the fields directly.

The server receives the authentication packet and extracts its fields:

$$P=\left\{ID,K_s,V\right\}$$

The server retrieves the outstanding nonce previously issued for the specified client:

$$N_s\leftarrow RetrieveOutstandingNonce\left(ID\right)$$

If no valid outstanding nonce exists, or the nonce has expired, the authentication request is rejected immediately. This constitutes the primary replay-protection mechanism. As a secondary defense-in-depth measure, the server checks whether the received session key has already been recorded in the UsedKeyLog.

If Ks ∈ UsedKeyLog then

Return REPLAY_DETECTED

Step 2: Query from user information: Depending on ID, the server checks the user’s availability in the database D.

If (ID ∈ D)

StoredHash ← Query(ID) = {H(UN||PW||salt) | (ID, hash, salt) ∈ D}

ExpectedToken = Hash(StoredHash∥Ks∥Ns)

Step 3: Recreate the Transformed Image: Using the received session key Ks, the server performs the same steps as the client to generate the encryption key and transform its local image I_S.

$${\mathrm{I}}^{\prime }=\mathrm{Enc}\left(\mathrm{Ks},\mathrm{I}\right)$$

Step 4: Derive Coordinates and Extract Values: Pixel values will be extracted from the encrypted image according to the received coordinates by using the function Fcoord().

{(x₁, y₁), (x₂, y₂), …, (x_m, y_m)} = Fcoord (V)

VS = [IS′ (x1, y1), IS′ (x2, y2), …, IS′ (x_m, y_m)]

RecoveredToken ← ASCII_Decode(VS)

Step 5: Validate the Authentication: The server compares the reconstructed authentication token (RecoveredToken) with the expected authentication token (ExpectedToken). Authentication succeeds only if the two values are identical.

$$Autenticatio{n}_{Result}=\left\{\begin{array}{c}SUCCESS If RecoveredToken==ExpectedToken) \\ FAILURE otherwise \end{array}\right.$$

The complete token Validation procedure is presented in Algorithm 2.

Algorithm 2 Token Validation

Input: Plain secret image I of size x × y, Authentication packet P={ID, Ks, V}, and the server-side nonce store mapping ID to its currently issued Ns and expiry.

Output: Authentication Result

1:   {ID, Ks, V} ← P                    //Extract packet fields 2:   Ns ← RetrieveOutstandingNonce(ID) 3:   If Ns = NULL or Ns has expired then 4:         Return REPLAY_DETECTED 5:   If Ks ∈ UsedKeyLog then 6:           Return REPLAY_DETECTED  // Reject replayed packet immediately 7:   If ID ∉ D then 8:   Return Error                         //Unknown user 9:   StoredHash ← Query(ID)    // Retrieve stored salted hash H(UN||PW||salt) from database 10: ExpectedToken ← H(StoredHash || Ks || Ns) 11: IS′ ← Enc(Ks, IS)              //Reproduce encrypted image using same session key 12: Initialize VS ← [] 13: For each (xi, yi) in V 14:       VS ← VS + [IS′[x_i][y_i]]          // Extract ASCII values from encrypted image 15: RecoveredToken ← ASCII_Decode(VS) 16: If RecoveredToken == ExpectedToken then 17:          Invalidate(Ns)  // Single-use: prevent reuse of this challenge 18:          Add Ks to UsedKeyLog  // Mark key as consumed 19:            Return AUTHENTICATION_SUCCESS 20: Else 21:         Return      AUTHENTICATION_FAILED

4. Performance

To evaluate the efficiency of the proposed image-based authentication protocol, all experiments were conducted on a workstation equipped with an Intel Core i7 processor, 16 GB RAM, running Windows 11 (64-bit). The proposed protocol was implemented in Python 3.12 using the PyCryptodome cryptographic library. A set of encryption algorithms (AES, DES, and Blowfish) was used on a variable-size grayscale image, as shown in Table 1 [38] DES is used in this evaluation only as a legacy performance benchmark to compare results with past evaluations and to compare computational overhead with previous evaluations. Currently, it is not recommended for practical use as it no longer offers sufficient cryptographic security. In practice, for the protocol proposed, the use of AES-128 or AES-256 algorithms is recommended.

Table 1. Impact of image size on encryption time and pixel repetition.

Image Size	Time taken (ms) Using Encryption Algorithms with Key Size (bits)			Repetition for Each Pixel (0–255)
	AES (256)	DES (56)	Blowfish (128)
255 × 255	0.10	0.70	0.42	≈235
512 × 512	0.71	3.01	2.02	≈1011
1024 × 1024	2.65	11.70	7.80	≈4031

These results indicate that the protocol’s implementation time is very suitable in terms of speed, considering that the choice of encryption algorithm type and image size is optional and depends on the type of application and its uses. Additionally, as shown in Figure 4, as image size increases, the frequency of pixel values after encryption increases, resulting in greater pixel spread and improved randomness, which helps prevent correlation-based attacks.

Figure 4. Relationship between Image size, Encryption time (ms), and Pixel reputation.

The transmitted packet size ranged from 100 to 150 bytes, depending on the length of the secret data s, the key length k, and the number of bits required to represent image coordinates derived from the image dimensions (W × H). The total packet size can be expressed as follows:

$$\mathrm{packet}\mathrm{size}={\displaystyle \frac{n.({\log }_{2}H+{\log }_{2}w)}{8}}+{\displaystyle \frac{k}{8}}$$

These results demonstrate high efficiency and speed, making them suitable for use in a wide range of applications, including mobile apps, browsers, and IoT systems.

Table 2 shows the total computational load required in the proposed DITA protocol at both the client and server. This test measures the total authentication delay (session-key generation, image transformation, coordinate extraction, packet construction, server-side image reconstruction, ASCII extraction, hash verification, credential comparison) while Table 1 measures only image transformation delay. As the image size grows, the total time required for authentication increases for all evaluated encryption algorithms, as predicted, since larger image sizes require more processing time and greater computational effort for coordinate search. The AES-256 algorithm consistently produced an objective benefit in terms of a low authentication latency among the evaluated algorithms while DES had the highest computational cost. In addition, the results show that the bulk of the overhead comes from the client side of the system, mostly due to the complete search of coordinates when generating tokens; the verification on the server side is nearly free. For the largest image size evaluated (1024 × 1024), the total authentication time remained within 42 ms, demonstrating that the proposed protocol is computationally efficient and well-suited to practical real-time authentication systems.

Table 2. End-to-End Authentication Latency of the Proposed DITA Protocol.

Image Size	Algorithm	Client-Side (ms)	Server-Side (ms)	End-to-End (Mean ± Std, ms)
255 × 255	AES-256	1.14	0.10	1.24
	DES	1.77	0.66	2.43
	Blowfish	1.47	0.43	1.90
512 × 512	AES-256	4.62	0.63	5.24
	DES	6.77	2.92	9.68
	Blowfish	5.82	1.84	7.65
1024 × 1024	AES-256	20.15	2.83	22.98
	DES	29.77	11.83	41.60
	Blowfish	25.67	7.96	33.63 ± 0.94

To determine the efficiency and responsiveness of the proposed system, experiments were conducted on three major parameters: image size, token length, and the number of users simultaneously, as shown in Figure 5. The time to each operation’s response was used as the performance measure. The experiments were conducted under controlled conditions and were sufficiently replicated to maintain stable results and to control for the influence of the system’s initial configuration. The effect of each parameter acting individually and the overall effect of parameters acting in combination was studied by systematically varying these parameters. These outcomes provide a clear picture of how the system will behave with respect to computational cost and scalability under varying operating conditions.

Figure 5. Impact of Image Size, Token Length, and Concurrent User Load on AES-256 Encryption Latency.

5. Threat Model and Security Assumptions

The security analysis of the proposed Dynamic Image-Based Authentication (DITA) protocol is achieved in the context of a very well-defined threat model. The adversary is given full access to the communication channel, and can eavesdrop, log, delay, replay, alter, or spoof packets from the client to the server and vice versa. There is, however, an assumption that the adversary cannot practically break the standard cryptographic primitives, such as AES, Blowfish.

In this study, two types of opponents are considered. The first one is a passive one that can only be used by a workaround to monitor the traffic passing through the network between the two legitimate users. Such an attacker can see authentication packets and extract communication data from multiple sessions but cannot modify the communicated packets. The goal of a passive adversary is to sift through the traffic and discover sensitive information or patterns in communication or authentication data that can be reused. The second type is an active enemy with all the capabilities of an active attacker and the ability to alter, replay, delete, or add packets to the communication stream. Such an opponent tries to masquerade as a legitimate user, compromise an authentication session or access a secured resource without authorization. This work addresses both passive and active attack scenarios.

The following assumptions are made for the security evaluation of DITA:

• Secure Registration Phase: The initial registration process which entails exchanging the shared secret image and protocol parameters, is done via a mutually authenticated secure channel (such as TLS/HTTPS). This channel cannot be compromised by the protocol.
• The Shared Secret Image is private to the two clients: The image shared with both client and server devices stays confidential and cannot be accessed by network-based attackers. This is the protocol’s biggest security need, the secrecy of this image.
• The security of the Image Transformation Algorithm: It is assumed that the symmetric encryption algorithm that maps the shared image is a standard cryptographic algorithm that offers standard security guarantees and that maps the image into a representation unique to each session, such that the mapping is not easily computable without knowledge of the original image.
• Secure Credential Storage: The user credentials on the server are never stored in plain text. Instead, they are protected using a memory-hard password-hashing or key-derivation function (e.g., Argon2, scrypt, bcrypt, or PBKDF2) applied to H(UN||PW||salt), where salt is a per-user random value. In the event that the credential database is leaked, resistance to offline guessing attacks depends on the strength of this memory-hard hashing scheme, the salt, and the underlying password strength—not on the shared image mechanism. The shared image and its associated coordinate-mapping table are used exclusively to generate valid, session-bound authentication packets (T = H(StoredHash||Ks||Ns)) during live authentication and provide no additional protection against offline attacks on an already-leaked credential database.
• The session keys are kept fresh: Each time a random session key (Ks) is required by the client during authentication, it produces a cryptographically secure random key. Once verified, the server records the session key it used in a lightweight used-key log and denies further authentication attempts using the same session key. This is a way to prevent replay of previously accepted authentication packets.
• Client-side image compromise: If the shared image stored on the client device is compromised, the attacker may reconstruct only the session-dependent authentication token $T=H\left(StoredHash\parallel K_s\right)$ from captured packets. Since $T$ does not reveal the plaintext credentials or the stored credential hash, and because $K_s$ is unique for each authentication session and cannot be reused after successful authentication. Leakage of the shared image alone is insufficient to impersonate the user in the future.
• Client-side Protected Storage: The client-side StoredHash is considered a secure local secret and assumed that the underlying platform provides secure storage facilities for it, if available. It can be the Trusted Platform Module (TPM) on the desktop, Android Keystore, Apple Secure Enclave/Keychain or other hardware-backed secure storage methods. These facilities are supposed to be used to stop unauthorized removal of the StoredHash from the client. In some situations where such secure storage is not possible or the client device is completely compromised, the level of security offered by the protocol may be lessened, like with other authentication protocols that depend on some secret stored locally in the client device.

6. Security Evaluation

The proposed protocol was evaluated using the same shared original image and unique random session keys across multiple sessions. Figure 6 illustrates the generation of different coordinates for the same user ID. This mechanism ensures replay resistance (each token is valid only once), eavesdropping protection (coordinates are meaningless without the shared image), and incremental attack resistance (coordinate locations change unpredictably in each session).

Figure 6. Illustration of session key variation and dynamic image encryption showing resistance to replay and eavesdropping attacks. The yellow cells indicate the selected pixel coordinates used for token generation, while the white cells represent non-selected pixels.

6.1. Replay Attack Resistance

Replay resistance measures a system’s ability to prevent the reuse of authentication packets for unauthorized access and user impersonation [17,39,40]. In the revised protocol, replay resistance rests primarily on a server-issued nonce N_s rather than on session-key randomness alone.

• Primary Defense: Server-Issued Nonce

For each authentication attempt, the server generates a fresh, cryptographically secure nonce N_s, binds it to the requesting client’s ID, and stores it temporarily with a short validity period. The client’s authentication token is bound to this challenge:

T = H(StoredHash‖Ks‖Ns)

Upon receiving an authentication packet, the server first retrieves the outstanding nonce it issued for the corresponding ID and verifies that it is still valid, before performing any database lookup or image reconstruction:

If Ns = NULL or Ns has expired then

Return REPLAY_DETECTED

Because N_s is single-use and is invalidated immediately upon successful validation, a captured packet cannot be meaningfully replayed once its associated challenge has been consumed or has expired—regardless of how long the attacker retains the captured packet. This directly addresses the log-expiry scenario: unlike the previous design, where a discarded UsedKeyLog entry could no longer distinguish an old packet from a new request, an expired or already-consumed N_s is rejected unconditionally, independent of any log retention window.

For the race-condition scenario—in which an attacker intercepts a legitimate client’s valid packet and forwards it to the server ahead of the client’s own transmission—the nonce confines the exposure to a single authentication attempt rather than allowing indefinite reuse. Since N_s is single-use, at most one of the two transmissions (the attacker’s relayed copy or the client’s own) can be accepted; once N_s is consumed, any further transmission of the same packet, at any later time, is rejected as REPLAY_DETECTED. This eliminates the unbounded replay risk previously associated with log expiry, though it does not by itself guarantee which of the two competing transmissions is accepted within that single window. Closing this residual live-relay exposure requires binding the authentication token to the underlying transport session, which we discuss as a deployment-hardening option in Section 6.6.

• Defense-in-Depth: Session Key Randomness

As a secondary property, each authentication attempt also uses a newly generated random session key, so that no two sessions produce identical coordinate-value pairs:

ks^(t+1) ≠ ks^t

The probability of generating an identical key across two sessions is inversely proportional to the key size:

Probability = 1/2^L

For a 128-bit key (l = 128): Probability = 1/2¹²⁸ ≈ 2.93 × 10⁻³⁹.

○

One-Time Authentication Packet

The authentication packet P is valid only for a single use:

P = (ID, Ks, V)

The proof V is derived from the session-bound token rather than from the plaintext credentials:

V = SelectRandomCoords(Enc(Ks, IC), T)

Since T incorporates both Ks and the server-issued Ns, a change in either value invalidates the packet for any other session:

k_s ^(t+1) ≠ k_s^t ⇒ V_s^(t+1) ≠ V_s^t ⇒ p_s^(t+1) is invalid for session^t

○

Secondary Check: Used-Key Log

As an additional defense-in-depth safeguard, the server checks whether $K_s$ exists in the UsedKeyLog. If $K_s\in \mathrm{UsedKeyLog}$, the authentication request is rejected as REPLAY_DETECTED. Otherwise, the server proceeds with validation and records $K_s$ in UsedKeyLog.

Because the primary replay defence is now the server-issued nonce rather than the used-key log, the log’s retention window is no longer security-critical on its own: even if an entry were removed, any corresponding replay attempt would already be rejected at the nonce-validation step, since Ns is single-use and short-lived by design.

6.2. Eavesdropping Resistance

Eavesdropping protection refers to the effectiveness of a protocol against intercepting and analyzing confidential communication data exchanged between the client and server [14,41]. Since the shared confidential image is not transmitted over the network, any intercepted data contains only random coordinate values and a temporary session key. An attacker cannot exploit encrypted data stolen from another connection because the image has been encrypted with a different key and the coordinates were randomly selected. It is impossible to correlate the intercepted information or convert it to valid credentials without knowledge of the image data stored between the client and server and the encryption algorithm.

6.3. Progressive Attack Resistance

The entropy of a progressive attack measures how resilient a system is to attackers who collect data from multiple sessions to find patterns or discover how the algorithm works [42,43]. Each session’s random key adds a high level of unpredictability to the encrypted image, creating a new mapping of coordinates each time. This makes it extremely difficult to guess the correct coordinates, as the probabilities are tied to the total number of pixels in the image in each session. This strengthens the protocol’s resilience against long-term statistical attacks.

6.4. Probability of Collision

Collision probability refers to the probability that two or more generated data items (such as keys, user information, or encrypted values) will produce the same output [44].

• Character collision

This type of collision measures the probability that two authentication sessions will match by producing the same coordinates from the cipher image or that an attacker will be able to forge the authentication credentials successfully. Let the shared image contain I = W × H pixels, and let the protocol extract m coordinates per authentication session. The probability that any two coordinates within a single session coincide follows the birthday bound:

$$P_{collesion}=1-exp\left(-{\displaystyle \frac{m\left(m-1\right)}{2N}}\right)$$

As shown in Figure 7, the test was conducted on a set of images of different sizes to evaluate the proposed system. The results showed that the probability of collisions decreases as the image dimensions increase, confirming the system’s effectiveness in reducing redundancy and ensuring coordinate diversity. It should be noted that collisions, if they occur, do not affect the system’s security. Their impact is limited to the attacker’s awareness of the presence of two or more similar characters in the encrypted data, without the ability to deduce or identify the original character.

Figure 7. Probability of character collision versus number of coordinates for varying image dimensions.

• Key Collision

When a new session key is generated for each authentication, there is a theoretically small probability that this key will match another key generated in a different session. When the key length is large (such as 128 or 256 bits), the probability of collision becomes practically negligible, because the product of the key size probabilities compared to the number of possible sessions is very large. If keys are chosen randomly from a key space of size K, the probability that two keys will match in S sessions is as follows:

$$P_{collesion}=1-exp\left(-{\displaystyle \frac{s\left(s-1\right)}{2\ast 2^k}}\right)$$

• User Collision

It occurs when two different users generate similar session keys and coordinates. The probability of a match in either the key or the coordinates generated by the image is practically impossible, as it requires a series of independent factors (key, image, random parameters) to match simultaneously.

6.5. Resistance to Compromise Attacks

In the proposed system, the shared image serves as an indirect representation of the token used in the authentication process and transmitted over the network. To ensure its confidentiality during the registration phase, the image is transmitted via an encrypted channel that prevents interception or leakage.

Conversely, user credentials are stored securely on both the server and user sides (e.g., secure hashing or encryption), ensuring they cannot be retrieved or used directly outside the context of authentication. This separation between the input element (the image) and the credentials, along with the image encryption method employed, reduces reliance on any single element during the verification process.

This multi-layered design achieves a high level of breach resistance, such that compromising a single element—for example, leaking the shared image—does not trigger a direct attack on the system. Effective exploitation requires compromising multiple independent security components simultaneously, increasing the complexity of the attack and enhancing the system’s resistance to partial breach scenarios.

6.6. Man-in-the-Middle Resistance

An active man-in-the-middle attacker can intercept, modify, replay, or inject authentication packets during transmission [45,46]. Against a purely passive observer, the protocol remains fully resistant: an attacker who monitors all network traffic but does not possess the shared secret image cannot construct a valid authentication packet, since the coordinates in V are meaningless without the image and do not reveal StoredHash. Against an active attacker, for successful authentication, the received coordinates, the session key, and the shared secret image must remain mutually consistent, so any tampering with the transmitted coordinates or session key produces a verification mismatch; combined with the server-issued nonce Ns (Section 6.1), this also prevents an attacker from constructing a new valid packet or blindly replaying a previously captured one. However, the base protocol does not bind the authentication token to the underlying transport session, so it does not resist a real-time relay in which an attacker positioned between client and server forwards a captured packet before it is consumed. Deployments that must resist this live-relay scenario should rely on an authenticated, integrity-protected communication channel, as recommended in Section 7, or on channel binding as an additional hardening measure.

7. Comparison

In this section, the proposed DITA protocol is compared with some representative authentication protocols, including OAuth 2.0, FIDO2 and HOTP, regarding computational burden, deployability, susceptibility to widely used attacks and communication security. This examination is not intended to make an absolute judgment of DITA’s superiority over other authentication protocols, but rather to place DITA in the context of other authentication methods in terms of design goals, security properties, and intended use.

In terms of the eavesdropping resistance, DITA is very resistant, because the shared secret image is only sent once in the secure registration step and not sent during any authentication session. As a result, any packet that is intercepted only has a temporary session key and randomly generated coordinates, which are of no use without the shared secret image. As far as replay resistance is concerned, the authentication packet is different for each authentication session, because the key used in the session is different. Once the user successfully authenticated with the server, the previous session keys are rejected by the server, so previous packets cannot be reused, which is equivalent to that of the challenge-response mechanism used by FIDO2, but it is done in a different security architecture.

The main difference between OAuth 2.0 and DITA is that while OAuth 2.0 uses a protected communication channel during the authentication and token exchange phase, DITA only uses a secure channel for initial registration to share the shared secret image. The authentication exchanges do not include long-term secrets; however, using an authenticated and integrity-protected communication path is recommended in practical deployments, to prevent packet manipulation and other active network attacks.

Proposed protocol adds more storage and computational overhead as each client and server has to store a shared secret image and transform images during the authentication process. But, as demonstrated in Section 4, the performance of this overhead is acceptable for intended deployment environments.

It is important to note that DITA is not designed to replace OAuth 2.0, FIDO2 or HOTP, which were designed with different trust models and operation goals. DITA, on the other hand, is intended for limited and automatic deployments, like machine-to-machine, embedded controllers, and IoT gateways, where hardware authenticators are either not available or cost prohibitive, and devices can be securely provisioned in the deployment. DITA offers a lightweight authentication system which generates authentication data for a session without the need for public-key infrastructure or counter synchronization in these environments. Table 3 shows the summary of the characteristics of the assessed protocols.

Table 3. Comparison of the proposed protocol with other protocols that are close in working principle.

Criterion	OAuth 2.0 [25]	FIDO2 [33]	HOTP [32]	DITA (Proposed)
Authentication Type	Identity Layer/Framework	Asymmetric Challenge-Response (Public Key)	HMAC-Based One-Time/Password	Dynamic Challenge-Response
Core Security Principle	Trusted Identity Provider issuing a signed JWT	Asymmetric cryptography (private key never leaves the authenticator)	Shared secret + Time/Counter	Secrecy of shared image + session randomness
Replay Attack Resistance	Strong (with TLS and recommended token management)	Very Strong	Strong	Strong (under DITA assumptions)
Eavesdropping Resistance	Strong (with TLS)	Very Strong	Good	Strong (shared-image assumptions)
User Experience (UX)	Highly seamless (Single Sign-On)	Seamless after enrollment (touch, biometrics)	Convenient but requires manual code entry	Seamless and automatic (after initial setup)
Complexity/Cost	Medium (Complexity on the server-side)	High (Requires supported hardware and browsers)	Low	High (Image management, computational load)
Client-Side Requirements	Minimal (Redirect to Identity Provider)	FIDO2-compliant authenticator (e.g., biometrics, security key)	Authenticator app or device	Secure image storage, encryption, and image processing capabilities
Trust Anchor	Identity Provider issuing signed access tokens	Private key stored exclusively on the authenticator; never transmitted	Shared HMAC secret provisioned at enrolment	Shared secret image provisioned once over a secure channel at registration
Key exchange	Client secret/keys registered; tokens exchanged over TLS	Public key registered at enroll; no shared symmetric secret	Shared symmetric secret provisioned at enroll	Secret image provisioned once over secure channel; per-session key sent in packet for image transform on server

The qualitative ratings assume recommended deployment practices for each protocol. OAuth 2.0 assumes TLS, PKCE, refresh-token rotation, and appropriate token management. DITA assumes secure provisioning of the shared image, protected client-side storage of StoredHash, server-issued nonces, and authenticated and integrity-protected communication channels.

8. Discussion and Limitations

The previous paragraphs discussed the capabilities of the DITA protocol in countering attacks, but there are a number of challenges. The first challenge lies in how to transmit the encrypted secret image during the registration process. The protocol requires a secure channel (such as TLS/HTTPS), and this requirement also applies when updating or replacing the shared image.

The second challenge for the system is the security of the image storing technique and the complexity of the image encryption process in comparison with conventional encryption systems. Optimized software implementation, hardware acceleration, and choosing an image size that is suitable for the target device and application can improve computational efficiency. In real-world deployments, the recommended encryption algorithms for the proposed protocol are modern cryptographically secure algorithms, such as AES-128 or AES-256. In the experimental results presented in Section 4, it is shown that these algorithms can give acceptable performance with only a minor impact on the overall system efficiency.

The number of coordinates may vary depending on the ASCII values, which may occur in small or unevenly distributed images. This is the goal of the third challenge: ensuring even pixel distribution. The fourth challenge is on the server side, which is providing additional space to store images and also the computational cost of the verification process in the event of a large number of users. We want to point out that most servers feature very high-performance processors in addition to large storage capacity.

9. Conclusions

The proposed system aims to ensure the confidentiality of tokens sent during the authentication process using a dynamic, one-time protocol based on an image encrypted with random keys. Random values are generated based on the image’s coordinates. Each authentication request produces a unique, non-reusable token, preventing reuse attacks while preserving the confidentiality of the shared image. It is worth noting that this algorithm has several strengths:

• Tokens are generated from encrypted secret image data, and the token is randomly encrypted from its coordinates.
• Security and execution speed depend on three elements (algorithm type, image size, and key length).
• Encrypted data is difficult for an attacker to analyze if stolen, as it is randomly distributed for each session and has no relation to the actual tokens.

The results demonstrate that this method offers an alternative to fixed token systems, preventing attackers from exploiting tokens if they are intercepted due to the different data in each authentication session. Furthermore, the authentication token, composed of coordinate values, is completely different from the user’s secret data, composed of letters, making it impossible for attackers to exploit or analyze the encrypted data. The average token generation time per authentication session was 11 milliseconds, demonstrating efficiency suitable for real-time applications.