6.7 KiB
Encryption Consumer Inventory
<style> table th, table td { vertical-align: top; } </style>Date reviewed: 2026-09-16
Implemented Clean-Break Decision
All listed consumers now write and read only Common's SACSENC2. AES-GCM envelope. Each operation uses a fresh 12-byte nonce carried in the envelope, a 16-byte authentication tag, and a consumer-specific purpose. The existing in-code keys are retained as agreed; fixed IV constants and per-session IV state are removed.
No legacy data needs to remain decryptable, so there are no dual readers or retention windows. Existing login cookies and session URLs are invalidated, outstanding password-reset and demo-registration links must be reissued, and coupled Windows-service clients and servers must be deployed together. Authentication failures fail closed and are never treated as plaintext.
Moving keys into protected configuration and adding key identifiers and rotation remains a future hardening task. Existing expiry and one-time-token checks remain necessary because authenticated encryption does not enforce either behavior.
Superseded Staged-Migration Analysis
The inventory below records the earlier compatibility-preserving analysis. Its dual-read and staged-retirement recommendations were superseded by the clean-break decision above and are not implementation instructions.
The shared envelope and rollout proposal is owned by Common in docs/authenticated-encryption-migration.md. This document records BusinessMgr-specific uses and migration constraints.
Consumers
| Consumer | Locations | Data lifetime | Current key/IV behavior | Migration requirement |
|---|---|---|---|---|
| Windows-service request and response traffic | SaBusMgrStandardBase/Base/Data/SbmWindowsServiceCrypter.cs, Base/WebService/SbmWebServiceClient.cs, and Base/WebService/SbmWebServiceResponse.cs |
Transient transport data, but independently deployed clients and servers may overlap versions | Separate embedded password strings for requests and responses; the former SacsAesIvCrypter supplied a random IV and legacy fixed-salt PBKDF2 key |
Deploy dual readers everywhere before version 2 writers. If clients cannot be upgraded atomically, add explicit protocol capability/version negotiation. Keep request and response purposes and keys separate. Never fall back to returning ciphertext as plaintext after an authenticated-envelope failure. |
| Control keep-logged-in cookie | SaBusinessMgrCoreWebControl/Control/Components/SbmController_Control.cs |
Persisted in the browser for 1–30 configured days (10 days by default) and survives application restarts | Embedded repeated/truncated key and fixed IV | Write version 2 cookies after dual-read deployment. Retain legacy reads for at least 30 days after the writer switch, then expire or reject remaining legacy cookies. Bind associated data to the Control cookie purpose. |
| Portal keep-logged-in cookie | SaBusinessMgrCoreWebPortal/Portal/Components/SbmController_Portal-Security.cs |
Persisted in the browser for 1–30 configured days (10 days by default) and survives application restarts | Separate embedded repeated/truncated key and fixed IV | Apply the same staged cookie migration independently from Control and retain legacy reads for at least 30 days. Bind associated data to the Portal cookie purpose and avoid accepting Control ciphertext. |
| Control and Portal password-reset links | Both SecurityController-Ajax.cs implementations and SaBusMgrCoreWeb/Web/Components/SbmController_Web.cs |
Persisted externally in email for 30–240 configured minutes (60 minutes by default) | Embedded keys and fixed IVs, with separate Control and Portal values | Dual-read links before changing writers. Retain legacy reads for at least four hours plus deployment overlap. Authenticate the application, link purpose, and version; continue validating the embedded expiry and one-time token. |
| Portal demo-registration links | SaBusinessMgrCoreWebPortal/Portal/Controllers/Home/DemoController-Ajax.cs |
Persisted externally for 30 minutes to 24 configured hours (60 minutes by default) | Dedicated embedded key and fixed IV | Migrate independently with dual reads for at least 24 hours plus deployment overlap. Use a distinct purpose from password-reset links. |
| Control and Portal session parameter URLs | SbmController_Control.cs, SbmController_Portal.cs, session-data classes, and their downstream controller/view call sites |
Session-scoped; keys change daily and IVs are generated per session | Date-derived embedded key plus a per-session IV | These can move after the shared parser is available. Existing links may be invalidated at deployment or accepted through legacy reads for the session lifetime. Version 2 must generate a new nonce per value rather than reuse the session IV. |
Cross-Cutting Findings
- The generic
SaController.EncryptParametersandDecryptParametersmethods hide whether data is a cookie, email link, or session URL. Version 2 APIs need an explicit purpose so authenticated values cannot be replayed across contexts. - Several keys and fixed IVs are embedded in source. They must be replaced by environment-provided key rings, with non-secret key identifiers in the envelope and no production secrets committed to either repository.
- Current decrypt wrappers often catch an exception and return an empty collection or even the original input. An authenticated version 2 value that fails verification must never be retried as legacy or treated as plaintext.
- Keep-logged-in cookie values contain account and organisation identifiers. Existing logging includes complete cookie values in debug messages; ciphertext should not be logged during the migration.
- Existing expiry and token checks remain necessary. Authenticated encryption prevents undetected modification but does not itself make a link single-use or enforce expiration.
Recommended Delivery Order
- Implement and test the shared Common envelope and key-ring abstractions without changing BusinessMgr writes.
- Add BusinessMgr configuration binding and secret deployment for separate Control, Portal, service-request, and service-response keys.
- Deploy dual readers for every consumer.
- Switch session URLs first because their compatibility window is shortest.
- Switch password-reset and demo-registration links, retaining legacy reads through their maximum expiry window.
- Switch keep-logged-in cookies, retaining legacy reads through their configured maximum lifetime.
- Switch service traffic only after all independently deployed peers support version 2 or negotiate capabilities.
- Remove legacy readers, embedded keys, and fixed IVs only after telemetry confirms that legacy traffic has ceased and the relevant retention windows have elapsed.