Short answer: SecurityBox preserves password history by inserting a separately encrypted vault version for every update instead of overwriting the previous ciphertext. Each version uses AES-256-GCM with a fresh salt and nonce, so earlier versions remain available while protected vault fields stay unreadable in MariaDB.
Passwords change, but the reason for a change is often just as important as the new value. A credential may be rotated after an employee leaves, updated during an incident, or changed as part of a regular security policy. If a password manager simply overwrites the old record, useful context disappears.
SecurityBox combines append-style password history with authenticated encryption. Every update creates a new encrypted version and retains the earlier encrypted versions. This provides a record of how the vault item changed while keeping its protected fields unreadable in the database.
How does SecurityBox password history work?
Every personal vault item has a stable item key and an increasing version number:
- The first save creates version 1.
- Each edit creates version 2, version 3, and so on.
- The newest version is marked as current.
- Earlier versions remain stored as history.
- The History page lists versions from newest to oldest, including their title, URL, username, note, saved time, and current status.
An update does not modify the encrypted bytes of the existing row. SecurityBox marks the previous version as non-current and inserts a newly encrypted row in the same database transaction. This append-style approach preserves the earlier record and avoids a moment in which two versions are unintentionally treated as current.
If someone edits an item but leaves the password field blank, SecurityBox carries the current password into the new version. This makes it possible to update a URL, username, title, or note without re-entering the password.
Deleting a personal vault item is different from editing it: deletion removes the item and all of its retained versions. Administrators should therefore include the database in an appropriate backup and recovery plan.
Which password-vault fields are encrypted?
SecurityBox groups the following vault fields into one protected payload before database storage:
- Title
- URL
- Username
- Password
- Note
The application serializes this payload and encrypts it before writing it to MariaDB. The database stores ciphertext rather than those values in readable form.
Some operational metadata must remain outside the encrypted payload so the application can locate and order records. This includes the owner ID, vault item key, version number, current-version flag, encryption salt, nonce, authentication tag, and timestamps. SecurityBox protects the vault content, but it does not attempt to hide the existence, ownership, version count, or timing of vault records from the database layer.
How does SecurityBox encrypt each password version?
SecurityBox uses AES-256-GCM for vault encryption. GCM is an authenticated-encryption mode: it protects confidentiality and detects accidental changes or deliberate tampering.
For every new version, SecurityBox performs the following process:
- It generates a new cryptographically random 32-byte salt.
- It derives a 256-bit encryption key from the installation master key and that salt using PBKDF2-HMAC-SHA-256 with 150,000 iterations.
- It generates a new cryptographically random 12-byte nonce.
- It encrypts the serialized vault payload with AES-256-GCM.
- It stores the salt, nonce, 16-byte authentication tag, and ciphertext with the version record.
Because every version receives a fresh salt and nonce, saving the same content twice does not produce the same encrypted database value.
Encryption architecture at a glance
| Component | SecurityBox implementation | Purpose |
|---|---|---|
| Encryption | AES-256-GCM | Protects confidentiality and detects tampering |
| Key derivation | PBKDF2-HMAC-SHA-256, 150,000 iterations | Derives a per-version 256-bit key from the master key |
| Salt | Fresh random 32-byte value per version | Makes each derived key unique |
| Nonce | Fresh random 12-byte value per version | Provides a unique GCM encryption input |
| Authentication tag | 16 bytes | Verifies ciphertext integrity and authenticity |
| Associated data | Vault owner's user ID | Cryptographically binds the encrypted record to its owner |
SecurityBox supplies the vault owner's user ID as authenticated associated data. The owner ID is not encrypted by this operation, but it is cryptographically bound to the ciphertext. Moving an encrypted personal-vault record to a different owner ID causes authentication to fail instead of silently decrypting it for another account.
When an authorized user opens the vault or its history, SecurityBox derives the correct key again, verifies the GCM authentication tag, and decrypts the protected payload in the application. A modified ciphertext, tag, nonce, salt, or owner binding will not pass authenticated decryption.
Is SecurityBox zero-knowledge or end-to-end encrypted?
No. SecurityBox uses server-side encryption at rest. It also scopes personal-vault queries to the authenticated user's ID, so a regular user, Admin, or Sa account cannot open another user's personal vault entries through the application simply because it has a higher application role.
Decryption occurs on the SecurityBox server for an authenticated and authorized request. The application and an operator with access to its master key can decrypt vault content. HTTPS is still required to protect secrets while they travel between the browser and the server.
How should the SecurityBox master key be protected?
The PasswordVault:MasterKey configuration value is the root secret used to derive vault encryption keys. Before production deployment, replace the default value with a strong, randomly generated secret and provide it through a protected configuration mechanism, such as a container secret or secrets manager.
The production master key should be:
- Kept out of source control and container images
- Restricted to the SecurityBox runtime and authorized operators
- Backed up separately through a secure recovery process
- Kept stable for existing data
- Rotated only through a planned re-encryption migration
Changing or losing the master key does not automatically re-encrypt stored records. Without the original key, existing password versions can no longer be decrypted. Database backups and master-key backups are both necessary for a usable recovery plan, and they should not be stored together without additional protection.
Why is encrypted password history useful?
- Rotation context: Teams can see when an entry changed and which version is current.
- Safer updates: Editing descriptive fields does not destroy the earlier encrypted record.
- Troubleshooting: Versioned details can help identify when a URL, username, or operational note changed.
- Tamper detection: AES-GCM rejects altered encrypted payloads instead of returning unverified data.
- Reduced database exposure: A database reader cannot directly read vault titles, URLs, usernames, passwords, or notes without the application master key.
History also increases the amount of sensitive data retained. Organizations should balance recovery and troubleshooting needs against their retention requirements, protect backups to the same standard as the live database, and delete vault items when their entire history is no longer required.
Frequently asked questions
Does SecurityBox overwrite an old password version?
No. An edit marks the previous version as non-current and inserts a newly encrypted row in the same transaction. Earlier encrypted versions remain in history until the vault item is deleted.
Can a database administrator read stored passwords?
Not from the database ciphertext alone. Decryption requires the SecurityBox installation master key and the application encryption process. Database metadata—including ownership, version count, and timestamps—remains visible.
Why does every version need a new salt and nonce?
The fresh salt produces a distinct derived key, while the fresh nonce gives AES-GCM a unique encryption input. As a result, identical vault content saved twice does not create identical ciphertext.
What happens if the master key is lost or changed?
Existing vault versions cannot be decrypted without the original master key. Changing the configuration value does not re-encrypt existing records, so rotation requires a planned migration and secure backups.
Does deleting a vault item retain its password history?
No. Deleting a personal vault item removes the item and all retained versions. Organizations should align deletion, database backups, and retention policies with their recovery and compliance needs.
A layered approach to password protection
SecurityBox password history follows a simple principle: keep useful versions without storing useful secrets as plaintext. Each update becomes a separate authenticated-encryption operation with new random material, while account-scoped queries control who can request decryption through the application.
A secure deployment should combine a protected master key, HTTPS, least-privilege database access, host and container security, monitored backups, strong user authentication, timely updates, and a retention policy appropriate for the organization.
For deployment guidance, see how to set up a self-hosted team password manager with SecurityBox. You can also explore SecurityBox features and deployment information.