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.

Expired shares are permanently deleted from our database within seconds. We do not maintain backups of credential data. Once deleted, recovery is impossible by design. This applies to time-based expiration, view limit exhaustion, or manual revocation.

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.