Security You Can Verify

CredenShare uses AES-256-GCM. For shares created on the web, the content key is generated in your browser and derived with HKDF-SHA256; it is carried in the link fragment, which browsers never send to a server, so we receive only ciphertext and a one-way access token. There is no split-key scheme and no password-derived key: losing the link means the share cannot be recovered, by you or by us. Shares created through the Slack app are encrypted on our servers instead, using keys held in a managed key service.

It depends where the share is created. On the web, your credential is encrypted in your browser before it is sent, and the key travels in the link rather than to us - so we hold ciphertext we cannot read. Through the Slack app, the credential passes through Slack first and is encrypted on our servers, with keys held in a managed key service under role-based access. Either way, data is transmitted over TLS and never stored in plain text.

Access to an expired share stops immediately, and the credential is deleted from our live database shortly afterwards — usually within the hour. Encrypted database backups are held for a short operational window, and they hold only ciphertext. Without the key from your link, nobody — including us — can recover the contents.

Access logs contain only metadata: timestamps, IP addresses, and access outcomes. No credential content is logged. Logs are retained for the duration specified by your plan (up to 180 days for Enterprise) and then permanently purged.

CredenShare follows SOC 2-aligned security and availability controls and is preparing for formal certification. Our infrastructure uses encryption at rest and in transit. We follow security best practices including least privilege access, infrastructure-as-code, and regular security audits.