CyberRiskEvaluator is a service of WEB-SET.com
follow us
© 2023 Created by: WEB-SET
Passwords, API keys, recovery codes, private notes and other sensitive information should never be shared as readable plaintext in email, chat or ordinary documents. A secure secret-sharing system should protect the content itself, restrict access to the encrypted record, separate the access link from the decryption passkey and minimize the amount of sensitive information processed by the server.
The CyberRiskEvaluator secure sharing approach combines AES-256-GCM encryption, a passkey-derived encryption key, a random salt, a unique initialization vector (IV), SHA-256 protected link tokens and browser-side decryption. The result is a simple workflow for the recipient—open the link, enter the passkey and reveal the secret—while the underlying cryptographic design provides several independent layers of protection.
A normal private link only controls who can reach a page. If the application stores the password or secret in plaintext, a database compromise, application vulnerability, accidental log entry or unauthorized server access may expose the information immediately.
Strong encrypted link sharing works differently. The secret is encrypted before it is stored, the access link uses a high-entropy random token, the server stores only a hash of that token, and the recipient must also know the separate passkey required to reconstruct the encryption key. The encrypted record and the decryption knowledge are therefore separated.
The protection model consists of two independent parts: access to the encrypted record and decryption of the secret. The link identifies the correct encrypted record, while the passkey is used to derive the cryptographic key needed to decrypt the content.
The sender enters the sensitive information to be shared, for example a password, API key or confidential note. A separate passkey is also defined. The passkey is not used directly as the AES encryption key. Human-created passwords and passphrases do not normally have the fixed length and uniform randomness expected from a cryptographic key.
Instead, the passkey is processed through a password-based key derivation function. This transforms the passkey into cryptographic key material suitable for strong symmetric encryption.
The passkey is combined with a random salt and processed with PBKDF2 using HMAC-SHA-256. PBKDF2 performs repeated cryptographic operations to derive a 256-bit key from the passkey.
This is important because a direct SHA-256 hash of a human password is intentionally fast, which is not desirable for password guessing resistance. A password-based key derivation process adds computational cost to every guess. The stronger the passkey and the more appropriate the key-derivation parameters, the harder an offline brute-force attack becomes.
In simplified form, the process is:
Passkey + Random Salt + Key-Derivation Parameters → PBKDF2-HMAC-SHA-256 → 256-bit AES Key
A new random salt is generated for the encryption process. The salt does not need to be secret and can be stored together with the encrypted record. Its purpose is to ensure that the same passkey does not automatically produce the same derived key across different records.
For example, two users could independently choose the same passkey. Because each encrypted secret has a different random salt, the key derivation result will be different. This prevents useful precomputation across records and avoids obvious relationships between secrets protected with identical passkeys.
AES-GCM also requires an initialization vector (IV), often described as a nonce. The IV is generated for the encryption operation and stored with the ciphertext. Like the salt, the IV does not need to be hidden.
The critical requirement is correct nonce management: the IV must be unique for encryptions performed with the same AES-GCM key. A securely generated IV ensures that repeated encryption operations do not reuse the same key-and-nonce combination.
The derived 256-bit key and the IV are used with AES-256-GCM to encrypt the secret. GCM is an authenticated encryption mode: it protects confidentiality and also verifies the integrity and authenticity of the encrypted data.
This means an attacker who changes the ciphertext cannot silently produce a predictable modified secret. When the recipient attempts to decrypt altered or corrupted data, the authentication verification fails and the application rejects the result.
The stored record can therefore contain the ciphertext and the non-secret parameters required for decryption, such as the salt, IV and key-derivation settings, without storing the readable secret, the passkey or the derived AES key.
Encryption protects the content, but the application also needs a secure way to locate the correct encrypted record. For this purpose, a long cryptographically random access token is generated and embedded in the sharing URL.
Instead of storing the raw access token in the database, the server stores its SHA-256 hash. When the recipient opens the link, the application hashes the supplied token and compares the result with the stored token hash. A valid match allows access to the encrypted record.
The simplified flow is:
Random Link Token → SHA-256 → Stored Token Hash
and later:
Token from URL → SHA-256 → Compare with Stored Hash → Retrieve Encrypted Record
SHA-256 has a different role here from PBKDF2. PBKDF2-HMAC-SHA-256 derives the encryption key from a human passkey, while SHA-256 can be used to store a verifier for the high-entropy random URL token instead of storing the raw bearer token itself.
One of the strongest architectural advantages is client-side decryption in the recipient's browser. After the encrypted record is retrieved, the recipient enters the passkey in the browser. The browser uses the stored salt and key-derivation parameters to reconstruct the same AES key, then decrypts the ciphertext locally.
The server does not need to receive the plaintext secret and does not need to know the passkey used for decryption. This reduces the exposure of sensitive information in application processing, server memory, backend logs and administrative workflows.
Modern browser cryptography can perform key derivation, encryption, decryption and hashing through cryptographic browser APIs, allowing sensitive operations to occur locally on the client device rather than requiring server-side plaintext processing.
AES-256-GCM provides strong symmetric encryption together with authentication of the encrypted data. The secret is protected against unauthorized reading, while tampering or corruption can be detected during decryption.
The encrypted link and the passkey can be shared through different communication channels. For example, the link can be sent by email while the passkey is communicated by phone, Signal, another trusted messaging channel or verbally.
Compromise of only one channel is therefore not automatically sufficient to reveal the secret. An attacker who steals the email link may be able to reach the encrypted record but still lacks the passkey required to derive the AES key. Someone who knows only the passkey still lacks the unique access link and encrypted record.
The backend can store only encrypted data and non-secret cryptographic parameters. A database breach therefore does not directly disclose readable passwords, API keys or notes. The attacker would still need the correct passkey to derive the decryption key for a captured ciphertext.
The encryption key is reconstructed from the passkey when needed rather than stored as a reusable plaintext AES key alongside the encrypted record. This avoids the common architectural weakness of keeping the encrypted data and the directly usable decryption key in the same database.
Decrypting in the browser minimizes the need for the application server to handle the readable secret. This reduces the number of places where plaintext can accidentally appear and limits the consequences of several server-side failure scenarios.
By storing only the SHA-256 hash of the random URL token, the database does not contain the original token needed to reconstruct the exact sharing link. This is particularly useful when the URL token itself has sufficient cryptographic randomness.
Secure links can be designed with a short validity period and automatic deletion or invalidation. A secret that is needed only for a few hours should not remain retrievable indefinitely. Expiration limits the time during which a stolen link could be abused.
The cryptographic process is sophisticated, but the user experience remains simple: open the secure link, enter the passkey and decrypt the secret locally. Security controls are most useful when they can be adopted without creating unnecessary operational friction.
If an attacker obtains only the database: the attacker may see ciphertext, salt, IV, token hashes, expiration metadata and key-derivation parameters, but not the plaintext secret or passkey. The passkey strength remains important because captured ciphertext can be targeted with offline password guessing attempts.
If an attacker obtains only the email containing the link: the attacker may be able to access the encrypted record, but still needs the separate passkey to derive the correct AES key and decrypt the content.
If an attacker learns only the passkey: the attacker still needs access to the correct encrypted record and its protected link token.
If the ciphertext is modified: AES-GCM authentication should cause the decryption operation to fail rather than returning silently manipulated plaintext.
The design is intentionally layered. No single mechanism is expected to solve every threat; encryption, key derivation, random salts, IV management, protected access tokens, separate-channel sharing, expiration and local decryption work together.
Strong cryptography cannot compensate for a weak or reused passkey. Use long, unique passphrases or randomly generated passkeys and communicate them through a genuinely separate channel. Protect the web application with HTTPS, secure the endpoint devices, avoid exposing secrets through browser extensions or malware, implement appropriate content security controls and ensure sensitive values are not written to analytics, application logs or error messages.
It is also important to understand the security boundary: browser-side encryption and decryption greatly reduce server-side plaintext exposure, but they do not protect a user whose device or browser session is already compromised. Endpoint security, phishing resistance and secure communication of the passkey remain essential.
The core strength of the solution is not a single algorithm but the combination of several controls. The secret is encrypted with AES-256-GCM, the AES key is derived from the passkey using PBKDF2-HMAC-SHA-256 and a random salt, every encryption operation uses an appropriate IV, the sharing link contains a random access token whose SHA-256 hash can be stored on the server, and the actual decryption takes place in the recipient's browser.
In practical terms: the server stores encrypted data, the link controls access to the encrypted record, and the separately shared passkey is required to decrypt the secret locally. This provides strong confidentiality, tamper detection, reduced server exposure, safer link handling and a simple workflow for securely sharing passwords and other sensitive information.
CyberRiskEvaluator is a service of WEB-SET.com
© 2023 Created by: WEB-SET