The software consists of two main components, a Backend and a Client:
the Backend is a python backend that runs on a physical backend and exposes a REST API
the Client is a user-side JavaScript web application that interacts with the backend only via XHR (XMLHttpRequest)
The entire application avoids the recording of sensitive metadata that could lead to the identification of reporters.
The confidentiality of authentication is protected by TLS version 1.2+, possibly also by Tor Onion Services v3 at the customer's request.
The system handles flows via containers managed with docker in rootless mode. The flows pass through a reverse proxy that manages the TLS connection (via automatically renewed Let's Encrypt certificates) and are analysed by a dedicated container, Coraza.
The system is based on the open source Globaleaks application, maintaining full consistency with the project's main channel, so as to ensure that patching and updating activities, also following periodic penetration tests and vulnerability assessments, are immediately applicable to client instances.
Below are the authentication methods implemented by the system.
Upon accessing the web login interface, administrators and report handlers must enter their username and password. If the password entered is valid, the system allows access to the functionality available to that user. The system implements the following password security measures:
passwords are never stored in plain text, but the system only keeps a hash of them at rest. This applies to any secret word, password or equivalent authentication information, including receipts from signallers
the platform stores users' passwords with a random hash having a 128-bit salt, unique for each user. Passwords are hashed using Argon2. The hash involves a user-specific generated seed for each user and a generated seed from the individual platform instance;
the system enforces the use of complex passwords by implementing a customised algorithm necessary to guarantee a reasonable entropy of each authentication secret
the system implements two-factor authentication (2FA) based on TOTP, with RFC 6238 algorithm and 160-bit secrets. Users can activate 2FA through their preferences, and the client can indicate its willingness to impose this requirement at the time of activation and, if necessary, during service delivery
the system requires users to change their password on first access. By default, the system requires users to change their password at least once a year. The customer may indicate a wish to change this timeframe at the time of activation and, if necessary, during service provision
The whistleblowers access their reports using an anonymous receipt, which is a randomly generated 16-digit sequence created by the backend when the report is first submitted
The system implements an automatic proof of work on each login that requires each client to request a token and solve a computational problem before being able to log in or submit a report. In addition, the system implements a speed limitation on whistleblower sessions by preventing the execution of more than 5 requests per second
The system identifies multiple failed login attempts and implements a slowdown procedure in which an authenticating client must wait up to 42 seconds to complete authentication. This function is intended to slow down any attacks that require more resources from users in terms of time, computation and memory
Web application security is implemented in accordance with the OWASP Session Management Cheat Sheet security guidelines. Cookies are intentionally not used to minimise XSRF attacks and any possible attacks based on them. Instead of using cookies, authentication is based on a customised HTTP session header sent by the client on authenticated requests
The backend integrates AppArmor by default and implements a strict sandboxing profile that only allows the application to access strictly necessary files. In addition, the application runs under a dedicated user and group with reduced privileges
The backend implements a protected local SQLite database that is accessed via the SQLAlchemy ORM. This design choice was made to give the application full control over its configuration, implementing a wide range of security measures in line with SQLite's security recommendations (such as secure deletion, auto-vacuum, limited database trust levels, deactivation of features not strictly needed)
Each instance is managed in dedicated docker containers, created and maintained in rootless mode, in order to further limit the chances of success of any attack attempts, by escalating privileges from the container to the server
Connections are analysed by a dedicated container, Coraza, produced by OWASP as the successor to ModSecurity, with daily rule updates (Owasp Core Ruleset), set to PARANOIA-LEVEL=1
If Coraza returns HTTP code 200, the flow is forwarded to the recipient instance by parsing the TAG TLS Server Name Identifier (SNI)
The platform on which our solution is based is subject to regular independent security audits to verify and improve the security of the system
In addition, a bug bounty project, hosted on HackerOne, is active
More information is available by clicking here
The hardware infrastructure is hosted by the German provider Hetzner Online GmbH:
rootless docker containers are instantiated within Virtual Private Servers
an additional perimeter firewall provided by Hetzner itself is active
physical access to the Hetzner infrastructure is monitored by means of guardian controls and active video surveillance
Multiple redundant connections to Germany's largest Internet exchange point, DE-CIX, ensure trouble-free data transfer
All existing upstream and peering is integrated into the backbone via state-of-the-art routers from Juniper Networks to increase network capacity
To safeguard web applications, websites, servers and IT infrastructure from DDoS attacks, Hetzner Online uses its automatic DDoS protection system
There is a central back-up server to save backup data. The RAID-1 hard disk system reduces the probability of data loss
Back-ups are performed on a daily basis with the following retention:
7 days for full virtual system backups
30 days for full backups of the instance data
On request, possibility to implement a cold storage system with a third-party European supplier