Cryptography Policy

​

Purpose

To ensure proper and effective use of cryptography to protect the confidentiality, authenticity, and integrity of information. This policy establishes requirements for the use and protection of cryptographic keys and methods throughout the entire encryption lifecycle.

​

Scope

All information systems developed or controlled by Neuroscale that store or transmit confidential data.

​

Policy

Neuroscale evaluates the risks inherent in processing and storing data and implements cryptographic controls to mitigate those risks where appropriate. Where encryption is in use, strong cryptography with associated key-management processes shall be implemented and documented. All encryption is performed in accordance with industry standards including NIST SP 800-57. Customer or confidential company data must use strong ciphers and configurations in accordance with vendor recommendations and industry best practices (including NIST) when stored or transferred over a public network.

​

Key management

Access to keys and secrets is tightly controlled in accordance with the Access Control Policy. Neuroscale operates two layered key-management surfaces, separated by purpose:

• HashiCorp Vault Transit — the application-layer envelope-encryption surface across both clouds. Application-level envelope keys, per-tenant customer-managed keys, and any encryption-as-a-service operations (encrypt, decrypt, rewrap, datakey, HMAC, sign) flow through Vault Transit. AWS-hosted and Vultr-hosted workloads call the same Vultr-hosted Vault cluster (per Secrets Management → Hosting) and key material never leaves Vault — applications receive ciphertext / plaintext but not the underlying encryption key. Key rotation, access reviews, and audit logging on Vault keys are governed by Vault’s audit device, with logs forwarded to Better Stack and to AWS S3 (Object Lock) for WORM evidence.
• AWS KMS — cloud-native at-rest encryption inside AWS-resident services. AWS KMS encrypts EBS, RDS / Aurora, S3, and DynamoDB volumes and objects (Neuroscale-managed CMKs where the data is Confidential or higher). AWS KMS is not Neuroscale’s application-layer KMS — its scope is the AWS provider’s at-rest encryption surface only.
• Vultr platform encryption — cloud-native at-rest encryption inside Vultr-resident services. Vultr Block Storage and Vultr Object Storage encrypt at rest by default with platform-managed keys.

For Confidential customer data on either cloud, the application-layer Vault Transit wrap is applied in addition to the provider’s at-rest encryption — so the ciphertext stored on disk is doubly protected, and the keys that matter (the Vault Transit keys) live in a Neuroscale-operated Vault cluster regardless of which cloud the underlying storage is in. The cryptographic-key-usage table below sets the algorithm/length/expiration floors. Key rotation, access reviews, and audit logging are configured per that table.

​

Recommended cryptographic key usage

​

Password hashing parameters

Password hashing parameters track the current OWASP Password Storage Cheat Sheet. Where Neuroscale operates a system that hashes passwords directly (rather than delegating to Rippling SSO), one of the following algorithms and minimum parameter sets must be used. Each password is stored with a unique, cryptographically random salt of at least 128 bits, and an application-side pepper is applied where feasible.

​

Salt vs pepper — what they are and why we use both

Salts and peppers are two distinct defenses against password-database compromise. Both are added to the password before it’s hashed; what differs is where each is stored.

• Salt. A unique random value generated per password and stored next to the hash in the database (e.g., as part of the encoded bcrypt / Argon2id string). Its job is to defeat precomputed-hash attacks (rainbow tables) and to ensure two users with the same password get different stored hashes. Salts are not secret — they are stored in plaintext alongside the hash and that is fine.
• Pepper. A single application-wide secret value stored separately from the database — at Neuroscale, in HashiCorp Vault (KV v2 path under the application’s namespace). Its job is to add a layer of defense against the specific scenario where the password database is exfiltrated but Vault is not: an attacker with the hashes and salts but no pepper cannot brute-force-guess passwords offline, because every guess would need to be combined with the unknown pepper before hashing.

In practice we apply the pepper by HMAC-ing the password with the pepper as the key (pre_hash = HMAC-SHA-256(pepper, password)) and then feeding pre_hash to bcrypt / Argon2id with the per-user salt. This keeps bcrypt’s input-length cap manageable and produces a uniformly distributed pre-hash regardless of the original password’s length or character set.

​

Pepper management

• The pepper is generated as a 256-bit cryptographically random value and stored in HashiCorp Vault at a per-application KV path. Rotation is supported via versioned values: the application reads the current pepper version for hashing, and reads the historical pepper version when verifying older hashes (the version number is stored in the encoded hash record). See Secrets Management.
• Application access to the pepper uses workload-bound Vault auth (Vault AWS auth method, Vault Kubernetes auth method, or AppRole — never a long-lived static token). The pepper never leaves the application’s process memory.
• The pepper is rotated on suspected compromise (treat as P0 / P1 — see Secrets Management → On compromise) and at least every 24 months under routine maintenance. Rotation requires a re-hash on next successful authentication for affected users, with the old pepper retained as a verify-only version until cutover is complete.
• Vault Transit is an acceptable alternative for systems where holding the pepper as application-readable secret material is not desirable: in that mode the application sends the password to Vault Transit’s HMAC endpoint and receives the pre-hash without ever holding the pepper itself. Either approach is approved.

Parameter floors are reviewed annually against the then-current OWASP guidance; deployed systems are re-tuned when hardware advances render the prior floor inadequate. Legacy hashes that fall below the current floor are rehashed on next successful authentication.

​

Key rotation cadence (consolidated)

The table below consolidates rotation expectations across key classes; per-secret rotation is governed by Secrets Management. Rotation evidence is captured in the relevant ticket and the Vanta evidence library and is reviewed during quarterly access reviews and the annual SOC 2 audit.

​

Operational requirements

• All laptops and mobile devices issued by Neuroscale have full-disk encryption enabled (FileVault on macOS, BitLocker on Windows).
• All TLS endpoints score A or better on SSL Labs (or equivalent) — the SSL Labs scan results.
• Secrets must not be committed to source control. See Secrets Management.
• Backups containing confidential data are encrypted at rest (see Operations Security).

​

Exceptions

Requests for exceptions must be submitted to the CISO for approval. A documented exception is required prior to moving, copying, or storing customer or company confidential data on any media or removable device. All portable devices and removable media containing sensitive data must be encrypted.

​

Violations & enforcement

Report violations to the CISO. Violations may result in suspension of system and network privileges and disciplinary action up to and including termination.

​

Version history