Threat Model
PrivateBin uses encryption to hide content stored by users on a server from the server administrator. This serves to protect the administrator from certain jurisdictions requirements to review stored content. The administrator should have plausible deny-ability of any content stored and would just remove it once made aware of illegal or otherwise inappropriate content.
Users are provided a service which lets them share content with less worry about content filtering, but still have to fully trust the administrator not to manipulate data, inject malicious code or exposing meta data about their activities to third parties.
This document focuses on the server side implementation of the service, as the client side code at the moment is delivered by the server, too, and so is completely dependent on a trustworthy server side.
The following scenarios are considered relevant to this threat model:
- installation of PrivateBin
- paste creation
- viewing a paste
- adding comments to a discussion
- deleting a paste
- using PrivateBin on a mobile device or a desktop operating system
- using a command line client with a PrivateBin server
We assume the following user types to use the software:
- administrators with access to a PHP based hosting environment (with or without HTTPS setup)
- anonymous users with internet access and a web browser or a command line client
- server operators that run PHP based hosting environments
These are the external dependencies that PrivateBin needs to function:
- JavaScript capable web browser or command line client
- PHP >= 5.5 with GD and mcrypt or PHP >= 7.0 with GD
- web server with PHP and ideally TLS support and a configured certificate
- writeable data directory and temporary folder (for PHP and web server)
- (optional) database with matching PHP module installed
It should be obvious that at least some of the following assumptions are questionable by their nature. Don't take these as given or look at them as guarantees of the maintainers. Some are clearly beyond the control of the software authors and others are based on best efforts (HTTPS as long as used only with trustworthy CAs, the assumption that the cryptographic libraries are used correctly).
Based on the above use of the software and the dependencies, the following assumptions have to fulfilled to provide a secure operation:
- the server is set up with at least one of PHPs supported sources of randomness for the server salt generation
- neither the server nor the administrator knows the key or content of a paste created by a user
- the web server may be configured to log users IP addresses, timestamps of the visits, request durations and other meta data
- neither the administrator, the server or a third party changes the JavaScript of PrivateBin
- the filesystem and database store data reliably, un-manipulated and allow access only to PrivateBin's PHP process and the administrator, in particular the data folder may not be accessible by a user via the web server
- neither the web server, PHP or the database run as root or other administrative user account
- the web server, PHP, database and underlying operating system and hardware don't have any know security issues
- the user can trust the admin and the server operators
- the environment of the web browser or command line client is not compromised
- the user keeps the key and optional password of the paste confidential
- only the intended audience gets hold of the key and optional password and accesses the paste during its lifetime
- the user isn't targeted by an entity able to adjust or inject JavaScript on the fly
- the user doesn't mind meta data leakage, especially but not limited to:
- which IP created a paste and when
- which IP viewed a paste and when
- the web browser doesn't store form contents or cache or screenshot pages containing any decrypted content
- the SJCL library and the Webcrypto API implementation of the browser don't have any security flaws (that we know of)
- the cryptographic libraries are used correctly
Informations for administrators on securing a PrivateBin installation are provided in the installation instructions.
The users are informed in the main project description about limitations of the software. They shouldn't use it in life or death scenarios or when their internet access is under surveillance.
| Element | S. | T. | R. | I. | D. | E. | Avg. | Notes |
|---|---|---|---|---|---|---|---|---|
| External Entities | ||||||||
| administrator (1) | 2 | 1 | 1 ½ | Can create valid delete tokens, manipulate all data | ||||
| anonymous user (2) | 3 | 3 | 3 | Has to brute force delete tokens, may send any data | ||||
| user with delete token (3) | 3 | 3 | 3 | Has to brute force (thrid parties) delete tokens, may send any data | ||||
| server operator (5) | 2 | 1 | 1 ½ | Can create valid delete tokens, manipulate all data | ||||
| Processes | ||||||||
| Controller (4.1) | 2 | 3 | 3 | 2 | 4 | 2 | 2 ⅔ | Spider in the web, indirect access to all data, including private |
| Request (4.2) | 2 | 3 | 3 | 2 | 2 | 4 | 2 ⅔ | Access to private data (IP, browser) |
| Configuration (4.4) | 4 | 3 | 3 | 3 | 3 | 4 | 3 ⅓ | Read only data access |
| Traffic Limiter (4.5) | 2 | 2 | 3 | 2 | 3 | 4 | 2 ⅔ | Access to private data (IP) |
| Server Salt (4.6) | 4 | 2 | 3 | 3 | 3 | 4 | 3 ⅙ | Write once, read many access |
| View (4.7) | 4 | 2 | 3 | 3 | 3 | 4 | 3 ⅙ | Read only data access, all dynamic data is injected by Controller |
| Model (4.3.1) | 3 | 3 | 3 | 3 | 4 | 4 | 3 ⅓ | Access to passed data |
| Filesystem / Database (4.3.2) | 4 | 2 | 3 | 4 | 3 | 2 | 3 | Read & write access to anonymous data |
| Paste (4.3.3) | 4 | 3 | 3 | 3 | 4 | 4 | 3 ½ | Access to passed data |
| Comment (4.3.4) | 4 | 3 | 3 | 3 | 4 | 4 | 3 ½ | Access to passed data |
| Data Stores | ||||||||
| Configuration file (4.8) | 2 | 4 | 4 | 3 | 3 ¼ | Edited by administrator | ||
| Traffic Limiter file (4.9) | 2 | 3 | 3 | 3 | 2 ¾ | Stores salted hashes of Ips | ||
| Server Salt file (4.10) | 3 | 4 | 3 | 3 | 3 ¼ | If leaked, allows to forge deletion tokens | ||
| Template (4.11) | 3 | 4 | 3 | 3 | 3 ¼ | If manipulated, could leak personal information | ||
| File / table row (4.3.5) | 3 | 3 | 3 | 3 | 3 | Contains meta data, but no personal data | ||
| Data Flows | ||||||||
| anonymous user request 2 → 4.2 | 4 | 2 | 2 | 2 ⅔ | Users raising too many requests to process, connection may be wiretapped | |||
| anonymous user response 4.1 → 2 | 3 | 4 | 4 | 3 ⅔ | ||||
| user with delete token request 3 → 4.2 | 4 | 2 | 2 | 2 ⅔ | Users raising too many requests to process, connection may be wiretapped | |||
| user with delete token response 4.1 → 3 | 4 | 4 | 4 | 4 | ||||
| Controller getting Configuration 4.4 → 4.1 | 3 | 3 | 3 | 3 | ||||
| Controller configuring Model, TrafficLimiter or ServerSalt 4.1 → 4.3.1 / 4.5 / 4.6 | 3 | 4 | 4 | 3 ⅔ | ||||
| Controller getting Paste from Model 4.3.1 → 4.1 | 4 | 3 | 4 | 3 ⅔ | ||||
| TrafficLimiter telling Controller if request can pass 4.5 → 4.1 | 4 | 3 | 3 | 3 ⅓ | ||||
| Controller getting ServerSalt 4.6 → 4.1 | 4 | 3 | 3 | 3 ⅓ | ||||
| Controller assigning variable in View 4.1 → 4.7 | 3 | 4 | 4 | 3 ⅔ | ||||
| View drawn for Controller 4.7 → 4.1 | 3 | 3 | 3 | 3 | Template could be made to leak data | |||
| administrator configuring system 1 → 4.8 | 4 | 4 | 2 | 3 ⅓ | A mistake in the configuration fail can make the system fail with an excetion | |||
| Model configuring Filesystem, Database, Paste or Comment 4.3.1 → 4.3.2 / 4.3.3 / 4.3.4 | 4 | 4 | 4 | 4 | ||||
| Model getting Filesystem, Database, Paste or Comment 4.3.2 / 4.3.3 / 4.3.4 → 4.3.1 | 4 | 4 | 4 | 4 | ||||
| Model creating or deleting data in Filesystem or Database 4.3.3 → 4.3.2 | 3 | 4 | 3 | 3 ⅓ | ||||
| Model getting data from Filesystem or Database 4.3.2 → 4.3.1 | 3 | 3 | 3 | 3 | ||||
| administrator or server operator manipulating data files or table row 1 / 5 → * | 2 | 2 | 2 | 2 | Both of these entities have to be trusted |
Threat levels are given from 1 (high) to 4 (low).
S.: Spoofing
T.: Tampering
R.: Repudiation
I.: Information disclosure
D.: Denial of Service
E.: Elevation of Privilege
Avg.: Average
Both the application administrator and the server operator can forge any meta data & data in the application, create delete tokens or delete data. We mitigate this risk by making the users aware of this and the application easy to install, so more users can host their own instances on trustworthy environments. A technical countermeasure would be to offer UIs that aren't dependent on a server, like CLI or other clients, including server federation.
The Controller sits in the middle of the data flows on the server. It is considered an acceptable risk given the benefits of using a single controller over the increased risks of a larger code base with separate controllers per API call or page view. Already implemented mitigations are the encapsulation of sensitive data structures in the Request and TrafficLimiter, to avoid exposing IP addresses or unprocessed request data to the internal logic.
While flooding of the network bandwidth, attacks on the servers IP stack, exploitation of the Kernels, web servers and PHPs yet unpatched bugs are considered outside of the scope of this application, the TrafficLimiter and other classes are used to mitigate duplicate content storing (on the meta data level, it is not protecting against re-encrypted identical content) and excessive use by a single source IP address (using a fixed rate-limiting per address, without increasing time-scales). A recurring mitigation is the ongoing maintenance of the software, keeping it compatible with the latest PHP and browser versions, as not to introduce reasons to keep using exploitable software versions.