Skip to content

FAQ

Jump to bottom Edit New page
El RIDO edited this page Dec 16, 2023 · 103 revisions

Please have a look at these questions before opening an issue in this repo.

General

Why is it named "PrivateBin"?

We asked the ZeroBin community when we decided to switch to a new name and chose the most popular name.

Why have you changed your name?

PrivateBin started as a fork of ZeroBin. The fork continued development after ZeroBin stopped being updated. Many new features were added, the general code structure improved and many security vulnerabilities fixed. Therefore it seemed appropriate to change the forks name, to reflect the huge development efforts which lead to the improved PrivateBin.

If I use PrivateBin and post the link in a forum, in social media, etc. is my content secure?

As long as you set no password, everyone who has the link can decrypt the content of a PrivateBin! The only way to prevent this is to set a long, secure password when posting. You can find many tips on how to create secure password online, one of the most famous ones is shown in this xkcd comic (explanation).

Which PrivateBin server should I use?

Generally it is recommend to host your own instance of PrivateBin. You can do this with cheap equipment directly at home, if you do not fear setting up a server.

If you cannot do this, you need to find a server that you trust. On the one hand this means you have to trust the server operator. For this a relative or friend may help you or even set up an instance.

If you decide to use one of the sites listed in the public directory you should check the technical measures the server administrator used, to decide if you can trust the server. Here is a small checklist:

  • Check if the server uses HTTPS in the address bar of your browser. On https://privatebin.net/ you can see that it does, because the address starts with https:.
  • Enter the web address into https://www.ssllabs.com/ssltest/ and let it check the server. The site checks the HTTPS configuration. We recommend that servers have at least an A rating. If they have less, you might look for a better server. If they have A+ you are on a good site!
  • Enter the web address into https://securityheaders.io/. Here we also recommend an A rating or better.

You can also use our convenient PrivateBin server directory, which has included many of such basic security checks to help you choose a server that fits you. Note, however, ideally, you should always choose a server of a server operator you trust.

If a requirement is not fulfilled but you still want to use a server, it is a good idea to contact the server administrator and ask them to improve it.

The URL is so long. Can't I just use an URL shortener?

Of course you can, nobody can prohibit you from doing so. However we generally do not recommend it. As said in the previous questions everybody who has the URL can view the PrivateBin. This includes URL shorteners, so when you submit your URL including the key, it can be retrieved from the shorteners access logs.

If you use an URL shortener, we recommend that you set a password and/or use a self-hosted one. If this is not possible, you may check if the URL shortener:

  • offers HTTPS on the page where you enter the PrivateBin URL
  • the generated short URL is a HTTPS-URL
  • does not publish the shortened URLs somewhere

If these requirements are fulfilled, you may consider to use it. If you additionally selected to destroy the PrivateBin on the first visit (burn after reading) or you did set a strong password on your paste (see this question), you can be fairly sure that nobody intercepts your message.

For server admins we do actually provide a way to integrate an URL shortener into PrivateBin. It is strongly suggested to set up that shortener alongside on the same server instance and with the same security considerations as the PrivateBin instance itself. Open-source software for this is available, e.g. YOURLS.

For additional information on URL shortener security and usage, read issue #725.

How can I delete a paste?

If you are a user of PrivateBin: When you create a paste, apart from the link to the new paste, also a delete link is displayed that you can copy and store for later, in case you want to delete the paste again.

Without the delete token, you have to wait until the paste has expired. Visiting the paste after the expiration will guarantee that it is deleted. Otherwise it will get deleted eventually during a purge cycle.

If you are running your own PrivateBin instance: The paste is stored in the data folder and you can find it (for example using the find or locate commands on Linux) easily, as it is named like the paste ID. This is the part or the URL of the paste between the question mark ("?") and the hash ("#"). With a configured a database, its the row with that value in the ID column.

Why should I use PrivateBin?

As a user...

  • you can keep secrets such as passwords out of chats and share them with others
  • you can choose a trusted provider (maybe a friend or even yourself when self hosting the service)
  • you can share files*
  • and set a limited life time*
  • you can discuss topics with other people

* Only available if the server admin has enabled this feature.

As a server admin...

  • you are protected against legal orders forcing you to scan the content you receive from your users (which is not possible with PrivateBin, as you don't have the keys of the pastes)
  • you provide a service for those who need it
  • you can customize the template and code of PrivateBin, everything is open-source

Should I switch from ZeroBin to PrivateBin?

In short: Yes.

The longer answer is: ZeroBin is not maintained anymore. Using software which is not maintained anymore is generally a bad idea, as it gets no security fixes. In this case you can have a look at the closed security issues and you'll see that there were quite a lot. Among others we handled all issues discovered by a security audit from 2014 and we enhanced the security further by implementing additional security features.

You can also look at the release notes of PrivateBin to see what else changed.

But JavaScript encryption is not secure!

Firstly, this is a statement, not a question. Secondly, we acknowledge this and are well aware that JavaScript can't provide the same level of security as other methods can do, because you still need to trust the server administrator not to deliver manipulated scripts. That is why we explicitly mention this conceptual issue in our Readme.

However, people have different security requirements and sometimes a fast way to send someone an encrypted message is needed. If you want to be secure against any attacks, we strongly recommend you to host your own PrivateBin instance and use transport encryption (HTTPS) to prevent any modification of the data sent and received by PrivateBin.

Can I upload/download the pastes with curl/wget/…?

You cannot do it that easily, because the whole purpose of PrivateBin is to encrypt the pastes. And this is done in your browser using JavaScript.

You could, however, imitate this encryption process in your own tool/application locally and only upload or download the ciphertext. For more information on how to do this, please have a look at our API docs. We do also provide a A proof-of-concept CLI client that does this.

Why does it not load embedded images?

The reason is PrivateBin uses a Content Security Policy, which – by default – disallows the loading of images embedded in a HTML or Markdown paste in PrivateBin. This e.g. prevents someone from tracking users with images loaded from third-party resources.

However, you can ask your server admin to change the CSP of the PrivateBin instance, so third-party images are allowed. The server admin has to change the img-src directive to include domains, where images are allowed to be loaded from. One can e.g. change it to img-src 'self' data: https: to allow images from all HTTPS sites (in addition to the defaults in PrivateBin).

Why does it show me an error about an insecure connection?

You may have seen the following message:

This website is using an insecure connection! Please only use it for testing.

If so, you accessed the PrivateBin instance over an insecure connections, such as plain HTTP. See the Readme describing what PrivateBin cannot provide to understand why a secure connection (that ensures integrity) is required.

In most scenarios, the server admin can fix this by setting up HTTPS, which we have another FAQ entry for. Note that in some rare cases, a connection can be secure even if you use HTTP. (such as when using onion services) PrivateBin automatically tries to detect these and do not show this warning in such a case.

However, even in these cases, you may have technical difficulties and PrivateBin may not work as expected, because some browsers limit some features such as the Web Crypto API (which PrivateBin makes use of) to a secure context. A browser known to do this is Chrome/all Chromium-based browsers (since v60). This is a deliberate decision of the browser makers (for their reasoning, also see the previous links) and the inclusion of the WebCrypto API is based on this decision by the W3C. There is nothing PrivateBin can do about this. Either your browser trusts that is a secure connection and PrivateBin can use the features it needs, or it cannot.

We will not be adding potentially problematic libraries to work around such an edge-case issue. As a server admin, you could manually do so by adjusting the PrivateBin templates to include another library, but this is done on your own risk.

Why does it show me the error "PrivateBin requires a modern browser to work"?

This error is displayed if the feature detection of PrivateBin discovers that your browser lacks a core feature, required for it to function (i.e. encryption, ECMAscript version 6, WebAssembly).

In most cases, this happens, because WebAssembly and/or the Web Crypto API has been disabled or is unavailable.
Internally, we use a WebAssembly library for compression, so when it is disabled you cannot read compressed pastes (note that compression is used by default, so most pastes will likely be compressed). However, you can still create pastes, as PrivateBin can store and read uncompressed pastes.

If the Web Crypto API is unavailable, PrivateBin cannot decrypt or encrypt pastes. As that is the core of what PrivateBin does, it just cannot work. See the FAQ entry "Why does it show me an error about an insecure connection?" for more details.

Here are cases, that are affected by this and the corresponding causes:

If you know another not yet documented case, where this error happens, feel free to create a new issue, or - if you already know the reason for the error - edit this FAQ entry to add it to the list above to document it.

Technical

What parts are or aren't encrypted in a paste?

The following things are encrypted end-to-end in the browser, before the up- and after the download:

  • paste text (without formatting, which is done after decryption)
  • files and file names
  • user names, if used in a discussion comment
  • discussion comments

What is not encrypted is certain meta data of a paste, in particular:

  • timestamp of the paste or discussion post creation (can be looked up on the filesystem per paste/discussion file or deduced from the server logs)
  • expiration time in seconds, if chosen
  • format of the paste (plain text, source code or markdown)
  • if discussions are enabled for a paste (true/false)
  • the IP based user icon, if a user name was given

What is not stored or transmitted at all:

  • generated decryption key of the paste, it is part of the URL after the hash
  • password, if given

All the encrypted items in a paste and its discussion use unique salts (the salts are not encrypted), hence one can't easily deduct i.e. two discussion user names being the same name without having the key. But you can deduct if the same IP was used in a discussion without decryption, as the user icons (generated when a user name is used) are not encrypted. Then again it is easier to gather this information via the server access logs.

How can I securely clone/download your project?

As of the PrivateBin 1.0 release we cryptographically sign our git commits and tags, so that you can verify we actually developed the software. Later, we also started signing the release archives on GitHub. Should the signature ever change, please look for a signed message of the current developers, which states that there is a new developer with a new signature or another valid reason, why the keys change. Here is the workflow you should use for verifying commits or tags:

  1. Download our public keys from PrivateBin.info.
  2. Verify the keys. Here are our fingerprints:
    @elrido: 1C2A 890A F113 5CEC 3681 666A 0F5C 940A 6BD8 1F92
    @rugk: ABA9 B8F6 F448 B07F D7EA 4A1A 05D4 0A63 6AFA B34D
    common git signing key: 28CA 7C96 4938 EA5C 1481 D42A E11B 7950 E9E1 83DB
    You can use gpg --list-public-keys --fingerprint to view the fingerprints of all public keys or gpg --with-fingerprint <keyfile.asc> to print the fingerprint before you actually import the key.
  3. (Optional) Import the keys and adjust the trust level. You can either sign the keys with your own or manually set the trust level to the highest one.
    Note: If you only update PrivateBin manually and do not automate the setup you can skip this step.

Now you have different ways to verify the integrity and authenticity of PrivateBin. If you get a message that the signature is untrusted you may have skipped the previous step. In you case you should check the fingerprint shown in the output. If no one is shown you have to check the key with gpg --list-public-keys --fingerprint as mentioned above.

  • You can verify the stable releases. If you go to the releases page you can find .asc signature files attached for recent PrivateBin releases. You can use them with a GUI tool or the CLI to verify the downloaded ZIP or TAR.GZ archives:

    $ gpg2 --verify 1.6.2.tar.gz.asc
gpg: assuming signed data in '1.6.2.tar.gz'
gpg: Signature made Fri Dec 15 06:21:08 2023 UTC
gpg:                using RSA key 28CA7C964938EA5C1481D42AE11B7950E9E183DB
gpg: Good signature from "PrivateBin release (solely used for signing releases)" [unknown]
gpg: WARNING: This key is not certified with a trusted signature!
gpg:          There is no indication that the signature belongs to the owner.
Primary key fingerprint: 28CA 7C96 4938 EA5C 1481  D42A E11B 7950 E9E1 83DB

    Do not forget to verify subsequent releases/release files in the same manner.

  • You can also verify the git source code at any time directly. Just use git verify-commit HEAD to verify the latest git commit or git verify-tag <tag here> to verify a specific tag. You should get a message similar to this one:

    $ git verify-commit HEAD
gpg: Signature made Thu Sep 15 15:23:54 2016 CEST
gpg:                using RSA key 0x05D40A636AFAB34D
gpg: Good signature from "rugk git (software signing only) <rugk@posteo.de>" [<trust level here>]
Primary key fingerprint: ABA9 B8F6 F448 B07F D7EA  4A1A 05D4 0A63 6AFA B34D

  • When using the git verification method, you can also easily verify the new changes, when updating PrivateBin by "pulling" the new changes from this repo. It is enough to just run git pull --verify-signatures. It will check the signatures automatically and will notify you if a commit is not signed by a trusted PGP key. Note that if you skipped step 3 the imported key is not trusted and the command may fail too. In this case you can just do a usual git pull and then use the steps explained above to verify the signature.

Currently, we usually sign releases with the "PrivateBin release" key and git commits with individual keys by the developer, who committed them.

Note: The GitHub wiki is currently not signed by anyone.

How should I setup HTTPS?

There are many guides and test tools, which may help you how to setup HTTPS. Here are some recommendations:

  • There is no need to buy a SSL certificate. You can get one for free from Let's Encrypt.
  • Use Mozilla's config generator to create a strong configuration. (we recommend the "Modern" configuration)
  • Test your server configuration with SSLLabs. You should try to achieve A+ (it's possible, really!).

The dark syntax highlighting looks broken, how can I fix that?

You are likely experiencing issue #439, i.e. you have set a light syntax highlighting style together with a dark PrivateBin website design. Try switching to the sons-of-obsidian syntax highlighting theme.

How can I change the "PrivateBin" name used on the website?

If you just want to change the name and it should be the same in all languages, just set the option name in your configuration file.

If you would also like to change other texts or links, you should change the translation files in the i18n/ folder. The title, the "Ignorance is bliss" motto and the message explaining about the project are right at the top of those files. This way you can have your very own English "FishBin", German "FischEimer" and Chinese "鱼缸" all on one site.

How to fix "There is no suitable CSPRNG installed on your system"?

This error means you do not have a cryptographically secure random number generator available on your system. This is a requirement of PrivateBin for security reasons.

If you think you have at least one secure CSPRNG installed, you can use the following test script to check which secure PRNG you actually support:

<?php
echo '<pre>PHP version used: ', PHP_VERSION, PHP_EOL,
    'extension libsodium is loaded: ',
    (extension_loaded('libsodium') ? 'true' : 'false'), PHP_EOL,
    '/dev/urandom exists and is readable: ',
    (is_readable('/dev/urandom') ? 'true' : 'false'), PHP_EOL,
    'extension mcrypt is loaded: ',
    (extension_loaded('mcrypt') ? 'true' : 'false'), PHP_EOL,
    'function mcrypt_create_iv exists: ',
    (function_exists('mcrypt_create_iv') ? 'true' : 'false'), PHP_EOL,
    'extension com_dotnet is loaded: ',
    (extension_loaded('com_dotnet') ? 'true' : 'false'), '</pre>';

If all these checks fail, you need to either: upgrade to PHP 7, install libsodium, add /dev/urandom to your open_basedir setting, install mcrypt (which also needs access to dev/urandom, so open_basedir must also be set) or install com_dotnet.

Why does the "Loading…" message not go away?

If PrivateBin seems to be loading for an infinite amount of time, this generally shows that the required JavaScript could not be loaded (although JavaScript is enabled in the browser). The result can also be seen in the browser console. If you see “integrity” or sha512 hash mismatch errors, this is likely the cause.
If you are using an Android phone, you may have a look at "How to make PrivateBin work on my Android phone with data saver mode?". Otherwise you should contact the server admin. If you are the server admin you may have a look at "How to make PrivateBin work when using Cloudflare for DDoS protection?" in case you are using Cloudflare and "How to make PrivateBin work when I have changed some JavaScript files?", which can also cause this error. Even if you have not deliberately changed any JS files, please look into that last FAQ. There are many ways files may get mangled with when setting up or updating PrivateBin or when the files are being transferred to the browser.

If this does not help, have a look into your browser console. If any Content-Security-Policy (CSP) failure messages related to PrivateBin appear (many are also caused by browser add-ons), you see that the CSP header (a security feature deployed by PrivateBin) prevented the JS files to load as they seemed to be modified. This is configurable, see here for more information.

If all previous steps did not help you you might report this issue to us, so we can have a look. Please include all browser console messages and preferably try it with a fresh browser/profile (and/or another browser) to make sure no add-ons are interfering.

How to make PrivateBin work on my Android phone with data saver mode?

As a user, either switch to a PrivateBin instance on a server offering HTTPS or disable data saver mode in Settings > Data Saver.

As a server admin, consider setting up HTTPS or add a "Cache-Control: no-transform" header for your PrivateBins JS resources in your webservers configuration.

More details on Google Chromes Data Saver mode on Android can be found at Google.

How to make PrivateBin work when using Cloudflare for DDoS protection?

Cloudflare works as a reverse proxy in front of your webserver. Apart from protecting your site against DDoS it acts as a man-in-the-middle even for HTTPS sites and by default tries to optimize your site for faster loading. Part of that optimization (currently) breaks our SRI used to ensure that your JS files don't get modified (actually it works as intended as Cloudflare does modify them).

To make PrivateBin work with Cloudflare you must explicitly tell it to not modify the javascript file by serving them with a specific header. Here an example of nginx configuration with the no-transform property in the Cache-Control header.

    location ~ \.js$ {
        # no-transform tells Cloudflare and others to not change the content of
        # the file and thus breaking SRI.
        # https://developers.cloudflare.com/cache/about/cache-control#other
        add_header Cache-Control "public, max-age=3600, must-revalidate, no-transform";
        try_files $uri $uri/ =404;
    }

If your shared hosting provider didn't provide access to server side configuration of nginx, you can change CF configuration to bypass caching. Documentation can be found here: CloudFlare Rules

  1. Login to your CloudFlare account and head to Rules section.
  2. Click on the "Create Page Rule" button.
  3. Add the domain/subdomain with path where your PrivateBin's JavaScript files is hosted e.g : notes.yourdomain.com/js/*
  4. Select "Cache Level" and set to "Bypass"
  5. Save and apply...
  6. Profit !!!!

How to make PrivateBin work when I have changed some JavaScript files?

First of all, of course the best option would be no to change these files, as it eases updates. We deploy a mechanism called SRI to make sure the .js files are not tampered with. Accidental changes to these files may be done on-transit (see the other FAQ questions) or by modifications to the saved files on your web server for various reasons. Some pointers:

  • Check the line endings and check for extra lines e.g. added to the end of the file with some text editor. They should match the files as PrivateBin provides it.
  • Check that any potential reverse proxy does not modify or cache (and optimize) the files. Flushing the cache by restarting your server may help.
  • If this does not help, there might be someone/something else interfering with these files. Most likely this is a (reverse) proxy, such as Cloudflare, certain VPNs, data saver modes in your client, etc. Try to use it from a different internet connection and a different device to figure out what is manipulating the files and if you can disable/circumvent it.

When changing the JS files (or adding new ones) is deliberate, you need to regenerate the SRI hashes in your template, so that they match the updated files.

What are the recommended file and folder permissions for Privatebin?

Depending on your setup, the PHP process may run under a different user then the web server. Here are a few common setup scenarios:

  1. "Classic" Apache web server with mod_php - In this case PHP scripts are run as child-processes of the apache server and as the same user as the apache server. Since there is only one user in this scenario that needs access, one could go with just owner level permissions (0600 instead of 0640 for example).

  2. Any webserver, PHP runs as (fast)cgi or PHP-FPM (fast process manager) process - here the webserver and PHP may run in separate users. This is very common on shared hosters, where each customers PHP scripts are run in their own user, so that they can't read other customers files, etc. For this setup to work, the owner needs to be set to the same as the php process (usually not something that you can change on a share hoster) and the group needs to be set to a group the web servers user is in.

The permissions need to look like this:

  • Directories: 0550 (read-only for owner and group, not accessible for others)
  • Data directory: 0750 (writeable for owner, read-only for group, not accessible for others)
  • Files: 0640 (writeable for owner, read-only for group, not accessible for others), created files get these permissions automatically

For most setups it is also possible to use the following script. Make sure to edit the users and folders where necessary.

#!/bin/sh
# directories of privatebin
pbpath='/var/www/privatebin/'
pbdata='/var/www/privatebin/data/'
# user, of PrivateBin and web server (may be the same, as explained above)
pbuser='php'
htgroup='www-data'
rootuser='root'

mkdir -p "$pbdata"

echo "chmod"
find "${pbpath}" -type f -print0 | xargs -0 chmod 0640
find "${pbpath}" -type d -print0 | xargs -0 chmod 0550
find "${pbdata}" -type f -print0 | xargs -0 chmod 0640
find "${pbdata}" -type d -print0 | xargs -0 chmod 0750

echo "chown"
chown -R ${rootuser}:${htgroup} "${pbpath}/"
chown -R ${pbuser}:${rootuser} "${pbdata}/"

How can I link to RAW pastes instead of taking users to a web page?

When a PrivateBin link is visited, the encrypted paste data is sent to the client, and the JavaScript on the page decrypts it. The PrivateBin hoster does not know the encryption key and thus cannot decrypt the paste preemptively, meaning that the raw paste cannot be downloaded directly from the server. A more detailed technical explanation is available here.

If running JavaScript on the client side is feasible, you could create a new template based on either the bootstrap or the page one, then strip it down as to only show the paste but no menu bar, logos, etc. – either strip out the HTML or introduce CSS to hide the elements that are not relevant.

How can I link to a read-only mode where users can't submit pastes?

PrivateBin does not have a concept of access control in itself, but a read-only mode can be achieved using some custom configuration. Keep in mind that:

  • This may enable phishing, e.g. an attacker could fake a login page.

  • There may be other security issues that are not obvious at the first sight.

  • Method 1: If you are only uploading pastes from the CLI client, you can create a custom template which strips out the New/Send buttons. However this will not prevent smarter users crafting a POST request themselves.

  • Method 2: In your web server's virtual host config, you could require basic authentication for POST requests. This means anyone can read the pastes but in order to submit one you need to log in.

  • Method 3: This is the most secure method, but also the most complex. You could run 2 instances of PrivateBin, one which is protected behind some basic authentication or an obscure URL, and another which runs as a user which doesn't have filesystem/database write access. Both can use the same install files but you can use the CONFIG_PATH environment variable to configure each one as necessary. The rewriting of URLs would have to be done in your web server.

See here for a longer discussion around restricting users uploading pastes. See the wiki page “Restrict upload using NGINX” for an exemplary explanation on how to achieve the method that is descried as “Method 2” above using cookies and nginx.

Copyright 2021 wiki contributors. Licensed under CC BY 4.0. The PrivateBin software itself is licensed differently.

Clone this wiki locally