Threat models

Threat models are an essential part of building secure systems (read more here). Establishing a threat model means understanding the robustness of a system against a given attacker and context. A big part of our work at Privy is also to communicate these threat models so developers and users can safeguard their products and protect themselves. We break down some threat models below. Please reach out to us at [email protected] if you have any questions.

As a reminder, Privy works to secure user assets and data in 3 main ways:

• Proactive security: Privy systems are engineered and built with security in mind. This means resource isolation and cryptographic architecture designed to prevent Privy or its developers from ever touching user keys. This also means doing cryptographic and infrastructure audits on a quarterly basis, as well as running a Vulnerability Disclosure Program and active Bug Bounty Program.
• Active monitoring: Privy systems are instrumented for active monitoring. This means automated alerts triggered by unexpected or abnormal activity and an on-call engineering team on standby 24/7. As our customers deploy apps, we work to monitor activity across the threat landscape online and collaborate with service providers to take down malicious threats.
• Defensive measures: Privy is built with failsafes to enable developers and their users to cut off access to key material in the event of an emergency. We work on pre-approved procedures for such instances with our enterprise customers and are always at the ready to protect user assets in the case of attack.

If you're a researcher interested in participating in our Bug Bounty or you believe you've detected a malicious threat relevant to Privy's work, please reach out to [email protected].

Building principles

Security is full-time work. Nonetheless, we recognize that wallets are not one size fits all and different apps will have different needs from a wallet system. A wallet used to protect someone's savings should not be the same as one built to mint a commemorative NFT from a movie showing. Privy enables both. Moreover, wallets should evolve with usage over time so they appropriately guard user assets. A user may be required to set up multiple MFA and recovery methods as part of their product journey, but that may not be the right initial onboarding for them.

In general, Privy works to give developers optionality so they can build the right experience for their users, all while guiding developers to implement appropriate standards to defend their products. We recognize tradeoffs inherent in any cryptosystem and to that end offer first-class support for all wallets, from an email-based embedded wallet, to browser extension wallets, to hardware-secured cold wallets.

Advice for users

When dealing with self-custodied assets, it is essential to be aware of threats on the web. There can be no exhaustive guide to this threat landscape but we will cover a few key threats below related to social engineering.

Social engineering is a form of attack where a user is specifically targeted to take some action on behalf of an attacker. An attacker may reach out (in disguise) to try and compel the user to take some action that will lead to a compromise. This often takes the form of phishing attacks—whereby the user is compelled to log into a rogue site that will then take over their credentials to impersonate them—or by having the user run malicious software on their machine. The easiest way to steal assets from a user is to successfully impersonate them, so any authentication data the user has should be deemed highly sensitive. Beyond this, if your users' browsers are running sensitive code (as it does for any wallet system), you should assume they will be targeted for exploit.

A few rules:

• Always check the domain of a website you are connecting to or of an email's sender before clicking a button or entering information.
• Never volunteer any information to a given person or domain if you are not sure why they need it, or they cannot prove that they are an appropriate party to share it with.
• Make sure you understand what software you are running or why. This software can be used to eavesdrop or steal data from you.
  • This means no saving bookmarks in your browser on behalf of someone.
  • This means no installing extensions in your browser on behalf of someone.
• When in doubt, use a different browser to do things you are unsure about.
• Privy and its customers will never ask you for any log in codes, private keys, or any other private information that can be used to impersonate you.

If something feels off, take a second to think through things. No matter how urgent a matter is, mistakes are irreversible in self-custodial systems and you will never regret taking an extra second to think through why you are being asked to do something or why a given interaction feels odd. If in doubt, look it up. You can also reach out to [email protected] with questions. We are always here to help.

Advice for developers

This section walks through Privy features and their utility for you. It is a companion to Privy's security primer. This is by no means an exhaustive list.

• Allowed domains: Required for all apps to prevent your Privy implementation to be run on a malicious domain impersonating you.
• CSP: Required for all apps to prevent XSS attacks.
• Http-only cookies: Recommended for all apps. Setting Http-only cookies will segregate user tokens required to interact with their embedded wallet from the rest of your site storage to prevent an attacker taking over your stack from accessing them. Note that these will degrade UX for PWAs.
• MFA: Recommended for all users with any assets in their wallets. SMS is not an available MFA option for any app with SMS enabled as a login method. By default, MFA will require users to approve a transaction before their keys can be reconstituted. This will prevent an attacker impersonating the user from transacting on their behalf.
• Password and cloud-based recovery: Recommended for all users with any sizeable assets in their wallets. Password and cloud-based recovery will require user input in order to reconstitute a wallet on a new device. This will prevent an attacker from doing so on their behalf. Note that assets will be irretrievable if a user loses both their main device AND recovery method.

Understanding threat models

The below summarizes some key questions but is not exhaustive. Please reach out to go deeper into threat modeling or other attack strategies. Beyond the above strategies,

Threats across applications

Q: Can an unauthorized application iframe the Privy iframe?

No, the Privy iframe enforces all frame ancestors must be an allowed origin set by an application admin within the Privy developer console.

Q: Can an unauthorized application send messages to the Privy iframe?

No, the Privy iframe only accepts messages from its parent frame. The iframe message handler checks the origin of messages received and confirms they are from an approved parent origin. Additionally, the Privy iframe requires a valid access token to authenticate messages received from its parent frame.

Q: Can a Privy customer tamper with another Privy customer’s iframe?

No, browser controls as well as authentication controls enforce isolation between applications. Iframe contexts across different sites run in separate processes and do not share memory.

Threats across users

Q: Can an unauthorized user access the wallet of another user within the Privy iframe?

No, a valid access token is required for a user to access their wallet. Specifically, the user access token is required to retrieve the auth share, which is necessary in order to reconstitute the wallet. Access tokens are only granted to authenticated users and are stored as either localStorage or http-only cookies depending on configuration.

Threats from the developer

Q: Can malicious code in the parent application result in unintended interactions with the Privy iframe?

Yes, the parent application controls the context in which a user wallet is embedded and must therefore protect their applications appropriately when using a wallet system. To counter these threats, Privy provides security features such as cloud and password-based wallet recovery and MFA to mitigate risk and protect users even when something goes wrong.

Threats from Privy

Q: Can a compromised Privy team member read user keys?

No. Privy cannot access user keys in any way and only orchestrates key shares so the user can recover them in their client.

Q: Can a compromised Privy engineer deploy unauthorized iframe code?

No, in addition to strict internal security policies, we have strong CI/CD controls that require the review of multiple engineers including all designated Code Owners for code to be deployed. Privy enforces strict MFA on all accounts, and are granted least-privilege permissions across its infrastructure.

Q: Can a vulnerable package or dependency result in unauthorized iframe code being deployed?

Supply chain attacks remain a risk for all modern software. We have protections in place to secure against these including active monitoring

Threats from the user context

Q: Can a user be tricked into giving access to their account?

Yes, Privy systems are subject so phishing and social engineering attacks leading to user impersonation. We recommend enabling MFA and cloud or password-based recovery to protect yourself against these attacks.

Q: Can browser extensions inject malicious Javascript into the iframe?

In certain cases, yes. Privy works to protect from unverified extensions and block extensions that violate certain directives. However, it’s important to understand that extensions have elevated permissions and may have access to things such as browser requests and responses. According to the W3C CSP standard, browser implementations should allow user-agent features to override policies. We recommend educating users to not install untrusted browser extensions and to enable MFA on their accounts.

Q: Can bookmarklets inject malicious Javascript into the iframe?

As above, in certain cases, yes. Browsers enable bookmarklets to bypass CSP settings and inject Javascript code onto pages. We recommend educating users to not install untrusted bookmarkets and to enable MFA on their accounts.

Q: What happens if browser security guarantees do not hold?

If the user browser is compromised via a zero-day exploit. Privy has an emergency kill switch set up to disable all endpoints that relay any key material to the user in order to prevent any attacker from accessing user accounts until the exploit can be patched.