.. _defenses: .. relock documentation service security, created by sphinx-quickstart on Wed May 14 18:37:20 2025. You can adapt this file completely to your liking, but it should at least contain the root `toctree` directive. Security defenses and limitations ================================= This section details how Relock actively defends against various common cyber threats and clarifies the inherent boundaries and limitations of its security model. It aims to provide a comprehensive understanding of Relock's protective measures and its specific scope of influence. Session compromise attacks -------------------------- Session compromise attacks aim to illegally gain control over a legitimate user's active session. This grants attackers unauthorized access to sensitive data, functionalities, and resources, bypassing traditional authentication after initial login. Via robust, multi-layered defenses, Relock comprehensively prevents or mitigates all key forms of session compromise: session hijacking, session fixation, and replay attacks. Relock's strength against all session compromise attacks stems from a set of foundational cryptographic mechanisms and continuous validation processes: * **Continuous validation via ephemeral keys:** Unlike traditional systems that validate a session token only once at login, Relock performs rigorous, cryptographically strong validation with every single request. This validation primarily relies on the dynamic, short-lived nature of ephemeral keys. This means that even if an attacker manages to briefly compromise or steal session information, it rapidly becomes invalid as ephemeral keys rotate and the proofs of their generation change. Consequently, this significantly reduces the "window of opportunity" for exploitation and immediately terminates any hijacked session due to invalid or missing cryptographic evidence. * **Split shared secret:** The shared secret used in Relock's operation is split between the client (stored encrypted in a cookie) and the server (the decryption key). An attacker who compromises only the client-side cookie does not possess the server's decryption key, making the stolen cookie useless for independently forging a valid session. * **Triple verification of the client:** Every request is subjected to a three-fold cryptographic verification: #. Validation of the encrypted shared secret from the client-side cookie. #. Verification of an ephemeral key proof, derived from a unique nonce issued by the server. #. Validation of the client's digital signature on the request, generated using the client’s private key never transmitted from the client. An attacker attempting to hijack a session would need to correctly forge all three of these dynamic, cryptographically linked proofs, which is exceedingly difficult without direct control over the legitimate client's Relock implementation. * **Integrated network location monitoring:** Leveraging its continuous, cryptographic verification engine, Relock actively monitors for changes in the client's network location during a session. Any suspicious deviation from established session patterns triggers immediate, automated responses, such as session termination or re-authentication challenges, effectively thwarting session compromise attempts originating from new or unauthorized IPs. While the above mechanisms form the core defense, each specific type of session compromise attack is uniquely thwarted by how these mechanisms combine and counteract its particular vector, often with additional dedicated features. Session hijacking ~~~~~~~~~~~~~~~~~ Session hijacking occurs when an attacker steals or intercepts a valid session identifier (e.g., a session cookie) and uses it to impersonate the legitimate user, gaining unauthorized access to their web application session. This often happens after initial authentication has already occurred. Relock's design protects against session hijacking. Specifically, the split shared secret ensures that a stolen client-side cookie is useless on its own. The triple verification of the client ensures an attacker cannot simply replay or forge credentials. Additionally, integrated network location monitoring allows for immediate termination of suspected hijacked sessions. Session fixation ~~~~~~~~~~~~~~~~ Session fixation involves an attacker providing a user with a pre-determined session ID (often via a malicious link) and then tricking the user into authenticating with that fixed ID. Once the user logs in, the attacker can then use the known session ID to take over the authenticated session. In addition to the defenses mentioned above, Relock incorporates specific features to thwart session fixation attacks: * **No static or predictable session IDs:** Relock does not rely on easily fixated, long-lived session IDs that remain static across the authentication process. Instead, its session management is built upon dynamic, cryptographically derived secrets that are constantly refreshed and tied to the client's unique properties. * **Cryptographic "handshake" post-authentication:** When a "new client" (even one attempting to use a fixed cookie) seeks to establish a Relock-managed session after initial authentication, the system engages in a cryptographic exchange to generate and split a new, unique shared secret. This process ensures that any predetermined or "fixed" cookie from an attacker is immediately invalidated or ignored in favor of a new, cryptographically secure session context. The server will generate a truly random, unguessable shared secret and send its encrypted portion to the client, effectively rendering any attacker's "fixed" ID useless. Replay attacks ~~~~~~~~~~~~~~ A replay attack occurs when an attacker intercepts legitimate data transmissions (e.g., a login request or transaction approval) and then re-transmits them at a later time to impersonate the user or repeat an action, even if the original message was encrypted. Relock’s design includes the following key properties specifically tailored to prevent replay attacks: * **Unique nonces (numbers used once):** For every request within a Relock-protected session, the server embeds a unique nonce into the webpage on response. The client must then use this specific nonce to generate the subsequent ephemeral key and the proof of its generation to be sent to the server. Since each nonce is used only once, an intercepted old request, if replayed, will be immediately rejected by the server because its associated nonce will no longer be valid or expected. * **Client's digital signature:** Each request sent by the client is accompanied by a unique digital signature generated by the client's private key. This signature is not static because it is cryptographically bound to the entire content of the specific request. Since the request content itself always includes dynamic elements, such as the unique nonce (received from the server) and the proof of ephemeral key generation, the data being signed changes with every request. This ensures that even minor modifications to a request, or any attempt to replay an old request, will result in a signature mismatch with the current session context, leading to immediate rejection. Using these sophisticated cryptographic and continuous validation techniques, Relock builds a "moving target" defense around the user's session, making it exceedingly difficult for attackers to establish or maintain control through common session compromise vectors. Cross-site request forgery (CSRF) --------------------------------- Cross-site request forgery (CSRF) is a web security vulnerability that tricks an authenticated user's browser into submitting unintended, unauthorized requests to a web application where they are currently logged in. The attacker doesn't directly access the user's session token or private data. Instead, they leverage the browser's automatic inclusion of legitimate session cookies with requests made to the target domain, causing the application to execute actions as if they were genuine user actions, without the user's knowledge or consent. Relock's design provides an effective defense against CSRF attacks by integrating a cryptographic form of anti-CSRF protection into every request. This often simplifies or replaces the need for traditional, complex anti-CSRF token implementations. * **Request integrity via digital signatures:** Relock requires that every state-changing or data-retrieving request from the client to the server be digitally signed by the client’s unique, device-bound private key. An attacker attempting to craft a malicious CSRF request from a different site cannot obtain the client’s private key or generate the correct cryptographic signature needed for the forged request. Even if the browser automatically attaches the legitimate session cookie, the absence of a valid Relock digital signature will cause the server to immediately reject the forged request as unauthorized and invalid. * **Unique nonce on each request (as anti-CSRF mechanism):** Every request in a Relock-secured session includes a unique nonce (number used once) that the client must cryptographically sign along with the request data. This dynamic inclusion of a server-issued, one-time value functions as a highly secure, per-request anti-CSRF token. An attacker attempting a CSRF attack would not possess the current unique nonce from the legitimate session context, and therefore, cannot generate a valid signature for the forged request. This makes it impossible for an attacker to simply "predict" or craft a generic forged request that would be accepted by the server. Cross-site scripting (XSS) -------------------------- Cross-site scripting (XSS) is a type of injection attack where an attacker injects malicious client-side scripts (typically JavaScript) into web pages viewed by other users. This usually occurs when a web application fails to properly validate or encode user-supplied input before it's displayed or stored. When a user’s browser loads the compromised page, the malicious script executes within the context of the trusted website. A successful XSS attack can have severe consequences, including: * **Session hijacking:** Stealing session cookies or tokens to impersonate the user. * **Credential theft:** Displaying fake login forms or redirecting users to phishing sites to steal login credentials. * **Data exfiltration:** Reading and sending sensitive data (e.g., from the DOM, local storage) from the user’s browser to an attacker-controlled server. * **Website content manipulation:** Altering the content or appearance of the web page. * **Arbitrary actions:** Forcing the user’s browser to perform unauthorized actions (e.g., changing passwords, transferring funds) on the legitimate site, as if the user initiated them. Relock does not prevent the XSS vulnerability itself, which requires proper input validation and output encoding by the application developers. However, Relock significantly mitigates many of the severe impacts of a successful XSS attack, particularly those that rely on forging or manipulating application requests for unauthorized actions or data exfiltration. Relock achieves this mitigation through the core cryptographic mechanisms applied to every request, making it extremely difficult for injected scripts to achieve their malicious goals: * **Protected client’s private key:** The client's unique, device-bound private key is inaccessible to injected client-side scripts, as it is typically stored in secure, hardware-backed environments such as a secure enclave, hardware security module (HSM), or the operating system's protected storage. This means even if an attacker executes code in the browser, they cannot generate valid digital signatures for unauthorized requests. * **Digitally signed requests:** Any attempt by an XSS-injected script to forge or modify a state-changing or data-retrieving request to the server will result in an invalid digital signature (as the script cannot access the private key to re-sign it). The server will immediately reject such requests. * **Unique nonce on each request:** Each request includes a unique nonce (number used once) that is also cryptographically signed along with the request data. This further complicates attempts by an XSS script to replay or manipulate requests, as it cannot predict or generate the correct nonce for a legitimate-looking request. Thus, while Relock isn't an XSS prevention tool, it acts as a critical last line of defense, severely limiting the ability of an injected script to perform malicious actions by preventing it from generating and signing valid, unauthorized requests to the application. Account takeover (ATO) attacks ------------------------------ Account takeover (ATO) attacks occur when malicious actors gain unauthorized control over a legitimate user's online account. These attacks leverage various methods to compromise authentication credentials or bypass security measures, ultimately leading to impersonation, unauthorized actions, and potential data loss or financial damage. Relock provides a robust and proactive defense against these pervasive threats. Its core protection against ATO is built upon the following mechanisms: * **Protected client’s private key:** The client's unique, device-bound private key is crucial for generating cryptographic signatures. This key is stored in highly secure, hardware-backed environments (typically a secure enclave, hardware security module (HSM), or the operating system's protected storage), making it virtually inaccessible to malware, injected scripts, or external attackers. * **Digitally signed requests:** Every state-changing or authentication-related request from the client to the server is digitally signed by the client’s private key. This signature covers the entire payload, ensuring that any unauthorized alteration to the data or attempt to forge a request invalidates the signature. * **Unique nonce on each request:** Each request includes a unique nonce (number used once) that is also cryptographically signed along with the request data. This adds a layer of freshness and anti-replay protection, making it impossible for attackers to simply "predict," reuse, or replay valid requests. These mechanisms combine to fundamentally change the security posture against ATO by making stolen credentials or compromised factors largely useless for gaining unauthorized access. Credential-based and authentication bypass attacks ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Credential-based and authentication bypass attacks primarily involve obtaining or guessing traditional user credentials (passwords, MFA codes) or tricking users into revealing them, often aiming to circumvent established authentication factors. While Relock does not prevent the attempted compromise or credential theft itself, it prevents the successful exploitation of these compromised credentials for account takeover through its core security mechanisms. Even if an attacker obtains a user's password, MFA codes, or other traditional authentication factors, they cannot successfully authenticate because they lack access to the user’s private key stored securely on the user's device. Without this key, the attacker is unable to generate the necessary digitally signed requests for login, making any authentication attempt fail cryptographic verification. * **Phishing (credential harvesting):** Attackers trick users into revealing their login credentials (user names, passwords, and often MFA codes) by impersonating trusted entities through fake websites, emails, or messages. The goal is to capture these details for later use. * **Malware-based credential theft (e.g., keyloggers and infostealers):** Attackers can deploy malicious software (e.g., keyloggers and infostealers) onto a user's device to secretly capture login credentials, session tokens, or other sensitive authentication data. * **Credential stuffing:** Attackers often use large lists of user name / password pairs (obtained from previous data breaches on other websites) to try logging into various accounts, exploiting the common practice of password reuse. * **Brute-force attacks:** Attackers systematically try every possible combination of characters (or common dictionary words) to guess a password or other authentication factor for a single account or a small set of accounts. * **Password spraying:** Attackers try a small number of common passwords against a large list of user names (rather than many passwords against one user name) to avoid triggering account lockouts on individual accounts. * **MFA bypass:** Attackers attempt to circumvent multi-factor authentication (MFA) mechanisms through various techniques (e.g., SIM swapping, MFA fatigue attacks, and proxying login sessions). Relock inherently acts as a highly secure, phishing-resistant form of MFA. Replay of authentication attempts ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ To gain unauthorized access to an account, an attacker can intercept a legitimate user's authentication request (or a challenge/response) and attempt to resend it later. Relock provides strong prevention against this kind of attack. The use of unique nonces for each request along with the requirement for the entire request to be cryptographically signed ensures that even if an attacker intercepts a valid authentication attempt, they cannot "replay" it successfully. The server expects a fresh nonce, and the replayed request's nonce would be invalid or stale, leading to rejection. Data tampering and integrity violations --------------------------------------- Attacks targeting data tampering and integrity aim to unauthorizedly alter, corrupt, delete, or insert data, compromising its accuracy and reliability. Relock provides a robust defense against a wide range of these attacks, ensuring the integrity of data exchanged with the application. Relock's defense against data tampering and integrity violations is primarily built upon the following core cryptographic mechanisms, applied to every request: * **Protected client’s private key:** The client's unique, device-bound private key is crucial for generating cryptographic signatures. This key is stored in highly secure, hardware-backed environments (typically a secure enclave, hardware security module (HSM), or the operating system's protected storage), making it virtually inaccessible to malicious software, injected scripts, or external attackers. * **Digitally signed requests:** Every state-changing or data-retrieving request from the client to the server is digitally signed by the client’s unique, device-bound private key. This signature covers the entire payload of the request, ensuring that any alteration to the data invalidates the signature. * **Unique nonce on each request:** Each request includes a unique nonce (number used once) that is also cryptographically signed along with the request data. This adds a layer of freshness and anti-replay protection, making it impossible for attackers to simply "predict" or reuse valid requests. Due to these mechanisms, Relock prevents and mitigates a wide range of data tampering attacks and integrity violations. Client-side request manipulation attacks ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Client-side request manipulation attacks involve the manipulation or forgery of request data either directly by an attacker or through malicious code operating within the client's environment, before the request is sent to the server, thereby attempting to compromise the integrity of application actions. Relock directly prevents the following attacks. Any unauthorized alteration or forgery of request data will invalidate the request’s digital signature. This invalidation occurs because the attacker lacks access to the client’s private key required to generate a valid signature for the tampered data, leading to the request's immediate rejection by the server. * **Parameter tampering:** An adversary modifies parameters within a legitimate request (e.g., changing prices, quantities, or user IDs) to manipulate application data. * **Insecure direct object references (IDOR):** When exploited for data modification, an attacker manipulates object identifiers (e.g., database record IDs) in requests to alter or delete data belonging to other users or entities. * **Malicious API calls:** Attackers directly interact with an application's backend API endpoints, sending crafted requests to modify, delete, or insert data, often bypassing the regular user interface. For the following attacks, Relock does not prevent the initial compromise or vulnerability itself (e.g., malware infection or injection vulnerability), but it significantly mitigates the resulting data tampering impact. Even if the initial attack is successful, the adversary typically cannot access the client’s private key to re-sign tampered requests, ensuring any attempt to modify or forge data via a request will be rejected. * **SQL injection:** An injection vulnerability that can lead to unauthorized data modification, deletion, or insertion into a database. Relock does not prevent the SQL injection vulnerability itself (which requires proper input sanitization by the application), but it mitigates the data tampering impact if it relies on a signed request. * **Man-in-the-browser (MitB) attacks:** Sophisticated malware operating within the user’s browser allows the attacker to modify data in real-time before it's displayed to the user or sent to the server, often without the user's knowledge. Relock does not prevent the malware from infecting the browser or from running, but it mitigates the data tampering impact. * **Adversary-as-a-browser (AAAB) attacks:** An advanced attack method that gives the attacker control over the user's browser environment (e.g., controlling the browser tab), enabling them to manipulate data and actions from within the legitimate browser session. Relock does not prevent the initial compromise or control of the browser tab, but it mitigates the data tampering impact. Adversary-in-the-middle (AiTM) attacks ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ In adversary-in-the-middle (AiTM) attacks, the attacker acts as a proxy, intercepting and modifying communication between the client and the legitimate server in real-time. These attacks compromise the integrity of communication in transit, specifically replaying or manipulating it by an intermediary proxy. Relock does not prevent AiTM attacks from initially occurring or a proxy from intercepting traffic; however, it mitigates the data tampering and replay impacts. If the attacker attempts to modify any data in transit or replay an intercepted request, they cannot incorporate the expected unique per-request nonce nor re-sign the tampered data with the client’s private key. The server will detect the invalid signature or stale nonce and reject the tampered or replayed request. Limitations ----------- While Relock provides a robust, cryptographic security solution designed to mitigate a wide array of modern cyber threats, it is important to understand the inherent limitations and scope boundaries of its security model. No single security solution offers an all-encompassing remedy, and Relock is designed to excel in its specific domain of securing the client-server interaction and validating client legitimacy within a broader cybersecurity ecosystem. This section outlines areas where Relock, by design, has inherent limitations or requires complementary security measures for comprehensive protection: * **Dependency on client-side security and device integrity:** Relock's core client-side security relies on the integrity of the client's unique, device-bound private key. This key is assumed to be stored securely in hardware-backed environments, such as secure enclaves, hardware security modules (HSMs), or the operating system's protected storage. A successful, deep compromise of these underlying platform security mechanisms (e.g., via rootkit or hypervisor-level malware) could potentially impact Relock's client-side operations and cryptographic proofs before they are properly executed or sent. While Relock's continuous server-side verification and anomaly detection (e.g., network change detection) would likely detect suspicious patterns from such a compromised host , the initial deep host compromise itself is outside Relock's direct prevention capabilities. * **Limitations on initial vulnerability prevention:** Relock is primarily designed as a robust authentication and session integrity solution that mitigates the impact of many attacks by ensuring the legitimacy and integrity of client-server interactions. However, it does not prevent the initial occurrence of certain vulnerabilities or compromises: * **Cross-site scripting (XSS):** Relock does not prevent the XSS vulnerability itself, which requires proper input validation and output encoding by application developers to prevent script injection. While Relock significantly mitigates the impact of successful XSS attacks by preventing injected scripts from forging valid, signed requests, it is not an XSS prevention tool. * **SQL injection:** Relock does not prevent the SQL injection vulnerability itself, which requires proper input sanitization at the application layer. Instead, it mitigates the impact of SQL injections, preventing unauthorized data alteration, corruption, deletion, or insertion in the database. * **Malware infection:** Relock does not prevent the infection of a user's browser or device by malware, such as man-in-the-browser (MitB) or adversary-as-a-browser (AAAB) attacks. While it mitigates the data tampering impact by preventing malicious code from generating valid signed requests, the presence of such malware could still affect the user experience or other aspects outside Relock's scope. * **Adversary-in-the-middle (AiTM) attacks:** Relock does not prevent AiTM attacks from initially occurring or a proxy from intercepting traffic. Its mitigation is focused on preventing data tampering and replay of intercepted requests. * **Credential theft (initial compromise):** Relock does not prevent the attempted compromise or theft of user credentials (e.g., via phishing, keyloggers, or brute-force attacks). Its strength lies in preventing the successful exploitation of these compromised credentials for account takeover, as attackers lack the necessary client-side private key to generate valid signed requests. However, if an attacker successfully compromises a user's login credentials before a Relock-managed session is fully established, the initial login attempt using those stolen credentials might not be directly prevented by Relock alone. * **Application-specific logic flaws:** Relock does not protect against inherent backend business logic flaws that could be exploited by valid, authorized requests (e.g., an authorized user abusing a poorly implemented feature to gain unintended privileges or bypass internal controls). * **Server data exfiltration scope:** In the event of a server-side data breach, Relock minimizes the impact of exfiltrated data related to the shared secret, as the server only stores the decryption key, not the full shared secret. However, if both the client's encrypted secret (e.g., from a compromised cookie) and the server's corresponding decryption key were simultaneously compromised and correlated (e.g., through a highly sophisticated, synchronized compromise of both client and server components), the shared secret could theoretically be reconstructed. Additionally, Relock does not prevent the exfiltration of sensitive static data (e.g., unencrypted customer PII, intellectual property, and application source code) directly from a breached server's file systems or databases, if that data is not directly involved in the real-time client authentication or session management process. * **Infrastructure and network-level attacks:** Relock primarily operates at the application layer, focusing on the integrity and authenticity of requests. It does not provide direct protection against: * **Denial-of-service (DoS/DDoS) attacks:** Relock doesn't prevent traffic floods designed to overwhelm server resources or network infrastructure. * **HTTP request smuggling:** This vulnerability arises from inconsistencies in how frontend and backend servers parse HTTP requests. Relock doesn't prevent the underlying parsing desynchronization. * **Human factors and misconfiguration:** While Relock offers "secure by default" configurations and robust controls, its overall security posture can be influenced by human factors and application-specific configurations. For instance, explicit declaration of unprotected routes by developers or insufficient administrative oversight of configurable security controls could introduce vulnerabilities outside of Relock's direct cryptographic protection. * **Insider threats:** Relock is designed to prevent unauthorized external access and impersonation. It does not prevent a legitimate, authorized user (who possesses their own valid client-side private key and credentials) from intentionally misusing their authorized access or exfiltrating data they are legitimately allowed to view. Robust access control, auditing, and employee monitoring solutions are necessary for insider threat mitigation.