Skip to main content

Security

To get in touch with the Privy security team, please reach out to security@privy.io.

info

You can read up on how Privy works.

Security is a moving target as the web changes and stacks evolve. Truly secure systems are hard to build and easy to misconfigure. Privy exists so you can better secure your users' data and focus on what you do best: building your core product. Our software aims to raise the bar for security as pertains to user data and level the playing field so you can compete with incumbents without having to choose between user experience and user safety.

We are working to empower users to regain agency over their digital identities and developers to build better products without putting users at risk. This all starts with secure systems and sensible defaults. Ultimately, you should not have to trust Privy if you do not want to, be it as an end-user or as a developer. Nonetheless, we will continue hosting secure building blocks for the Privy system to make your life simpler and more secure, should you choose to use them.

The below provides an overview of Privy's threat model as pertains to managed infrastructure, including relevant controls we've put in place. All of these will evolve over time, as the threat landscape on the web evolves and as we decentralize our systems. Through all of the below systems, we adhere to principles of transparency (no security through secrecy) and least privilege. Our communication channels are end-to-end encrypted, any Privy data is encrypted at rest and all user data is encrypted client-side using keys secured by the user themselves or in specialized architecture segregated from the rest of the Privy stack. All data access is scoped by roles and we rely on strong user authentication to identify requesters. We are working to surface immutable audit logs to developers and end users to make Privy activity easily auditable.

info

This page is mostly about Privy managed infrastructure. As Privy decentralizes some of its infrastructure, these details will be provider-specific.

High-level guaranteesโ€‹

Privy makes the following guarantees:

  • Privy never accesses any user data at any time.
  • Only requesters with the appropriate permissions can access and decrypt data they are entitled to see.
  • Only the data admin can set permissions for any data.
  • Any data stored with Privy can be easily exported.

Today Privy manages the following architecture:

Read about how Privy works at a high-level.

Overviewโ€‹

All user data is encrypted client-side using AES-256-GCM and keys generated client-side. These keys are encrypted using asymmetric keys managed server-side (or in the future by the userand secured by HSMs.

  • Third Party VPC -- runs HSMs and HSM audit logs.
    • Privy uses a third-party provider (AWS) to run its FIPS 140-2 validated HSMs in order to generate and secure encryption keys for every Privy end-user.
    • All HSM activity is logged by a third-party audit log.
    • Only the KMS can connect to the HSM to run a limited set of cryptographic operations.
    • Only the HSM can write to the audit log.
  • Hardened VPC -- runs the KMS.
    • Privy runs a Key Management Service from within a hardened network.
    • Machines in this environment are locked down and do not accept SSH connections.
    • Code deployed in this environment is not continuously integrated but has been reviewed by multiple Privy team members.
    • Any call to the KMS must be made by an authenticated requester.
  • Privy VPC -- manages permissions and stores user ciphertext.
    • Runs a microservices architecture in a secure cloud environment.
    • SSH access is limited to authorized Privy developers.

If Privy's VPC were to be breached, an attacker would only gain access to the encrypted user data in question. Privy would then trigger reencryption to reencrypt all user data and flush all keys with corresponding compromised ciphertext from the KMS.

Traffic managementโ€‹

All traffic to console.privy.io, api.privy.io, and related subdomains is routed through Cloudflare. All of Privy's servers run within private VPCs on AWS.

TLS Encryptionโ€‹

All traffic is encrypted with a minimum supported TLS version of 1.2 and HSTS.

Backups and durabilityโ€‹

Privy takes full database snapshots on a daily basis and uploads transaction logs for database instances to backup storage every 5 minutes. These snapshots are stored for 7 days, accordingly Privy can safely restore databases to any point in the last week (with 5 minute granularity) as needed.

Encryption at restโ€‹

Privy-managed databases are encrypted at rest, independently from the fact that any user-data is itself encrypted end-to-end.

Audit logsโ€‹

Privy's HSM system currently has immutable audit logs generated via Amazon Cloudwatch. Every wrapper key generation, and data key encryption or decryption event appends an entry to the log. In parallel, Privy logs data accesses from the KMS. Privy plans to open up these logs to all users and developers in the near future. This will enable end-users to verify how their data is used, as well as developers to audit HSM usage on their end.

Developer Authenticationโ€‹

Privy currently supports email/password authentication. All passwords are hashed and salted using bcrypt. No preimages are stored with Privy. Additionally, passwords must have a minimum length of 10 characters, including non alphanumerics. Password resets are done using randomly generated tokens that expire after 6 hours.

End-user Authenticationโ€‹

Privy supports multiple authentication methods for end-users. Today, this means JWT-based authentication or authentication based on a user's own web3 wallet.

Privy piggybacks off of developers' existing auth system using JWTs. The appropriate admin on the developer-end can sign the appropriate JWT to authenticate their user. Privy generates Ed25519 keys based on the API secret.

The API secret is never stored on Privy servers and cannot be recovered once downloaded. Privy client libraries enable JWT generation and signing client-side on the developer stack. A developer can also override this default behavior to use custom signing keys to sign JWTs.

Allowable JWT signature algorithms include:

  • RSA: RS256, RS384, RS512
  • EdDSA: EdDSA (Ed25519 keys)
  • Elliptic curve: ES256, ES384, ES512

End-users can also authenticate directly with Privy using their existing cryptocurrency keys. Privy integrates directly with existing standards like Sign in with Ethereum (SIWE) through which users can sign messages to authenticate themselves directly with Privy. All such authentication is done using client-side signatures generated with user keys that never leave user wallets.

Data accessโ€‹

Select Privy developers can access customer metadata in order to help with any troubleshooting or outstanding issues. This includes data like field names, end-user ids, or access group compositions. Privy's systems are designed such that customer metadata cannot be accessed without explicit customer approval.

Privy cannot access end-user data without signficant modification to its systems and will never do so unless compelled to do so under threat of law.

Code audits, pentesting and bug bountiesโ€‹

Privy's client libraries are open-sourced and have undergone multiple rounds of reviews by security engineers and cryptographers. Privy's internal infrastructure has undergone multiple rounds of audits by third-party testers and developers, as well as a round of pentesting.

Security is a constantly moving target and we will undergo such auditing and testing multiple times a year on a regular basis to surface and address new issues.

We will be setting up a bug bounty program in the near future. Please get in touch with the security team at security@privy.io.