Security

Trust Assumptions

CryptPad is end-to-end encrypted and the server has no access to your data. However, as with any other web application, some entities still need to be trusted in order to guarantee security:

• Your chosen CryptPad instance to

  • run the same code as the one published on GitHub,

  • not block your network messages, and

  • follow its terms of service and privacy policy.

• Your collaborators not to forward sharing links to illegitimate third parties.

Under these assumptions you can be sure that it is technically not possible to read or modify your documents by

• your chosen CryptPad instance,

• any powerful adversary that can see your web traffic, or

• any other user.

We maintain a list of public CryptPad instances to let you better decide on whom you want to trust.

Warning

CryptPad does only provide a weak form of anonymity. Your chosen CryptPad instance can see your IP address and your "user agent" (browser and operating system).

If you need stronger anonymity guarantees, you can access CryptPad via Tor.

Passwords for documents and folders

Logged in users

When you share the link to a document or shared folder through an insecure channel (for example email or SMS), someone might intercept the link and gain access to your data. To prevent this from happening, the owners of a document or folder can add a password.

When you share documents with your contacts and teams directly on CryptPad, communications are encrypted and we assume that you want to give them access. Therefore the password is remembered and sent with the document/folder when you share it. The recipient, or yourself, are not asked for it when they open the document.

You can add a password to a document when you create it.

You can also add or change the password in the Access menu:

• From the CryptDrive: Right click > Access.

• From the document toolbar: Access.

Verifying contacts

Logged in users

To verify a contact's identity, i.e., that a contact belongs to the person you think, you can compare the public signing keys:

1. Ask your contact to share their public key over a secure channel with you.

2. If this public key matches the one from your contact's profile page, you can be sure that the contact belongs to the person at the other end of the secure channel.

Self-destructing documents

Logged in users

Self-destructing documents will be destroyed automatically without the interaction of any user. This ensures that sensitive data is not accessible forever.

There are two ways to create self-destructing documents:

• You can set an expiration time during creating.

• You can share a document via a view-once-and-self-destruct link.

Remote Disconnect

Logged in users

In some cases (loss or theft of a device, forgotten to log out of a session on a shared computer, etc.) it can be necessary to close all active CryptPad sessions. This can be done in two ways:

• User menu (avatar at the top-right) > Settings > Confidentiality > LOG OUT.

This option logs out all sessions except the one from which it is activated.

• User menu (avatar at the top-right) > Log out everywhere.

This option logs out all sessions including the one from which it is activated.

Remote Content

In Markdown editors (Code / Markdown, Slides, Kanban), CryptPad blocks images and other remotely hosted content to prevent potential tracking.

Logged in users

To include images from the CryptDrive or to upload new ones, use the Insert menu. This menu inserts a media-tag element that is more complex than Markdown image syntax but is managed automatically.

Known caveats

No unique usernames

Neither the account name nor the display name is unique in CryptPad. This means that you cannot trust usernames to identify people. Instead, identify your contact via their public keys.

Edit rights in teams

Team members with edit access to a teams drive may share this access to other users both inside and outside the team. Team members may even convert folders into shared folders and delegate their access to anybody they want.

You therefore have to be careful with whom you grant edit rights. You may also want to

• set the role of a member to viewer and selectively share edit rights to this person.

• use access lists to limit the access to a file to specific contacts.

Access of former team members

The team communication is encrypted with static keys. This implies that a former team member still has the keys. A former team member can therefore potentially decrypt team messages and can also keep the same access to the team's document as before. However, this requires to modify the client source code as the official one does neither store the keys nor decrypt any messages of a team which the user is not part of.