Link Search Menu Expand Document

Bezpieczeństwo aplikacji

Skrzynki kontaktowe wdrożone w ramach Bezpieczny Kontakt korzystają ze standardów branżowych i praktyk zaimplementowanych przez zespół GlobaLeaks. Połączenie wielu sprawdzonych i nowoczesnych technologii pozwala zapewnić wysoki standard bezpieczeństwa dla sygnalistów.

Spis treści
  1. Architektura
  2. Anonimowość
  3. Bezpieczeństwo sieci
    1. Anonimowość połączenia
    2. Szyfrowanie połączenia
  4. Uwierzytelnianie
    1. Hasło
    2. Kod zgłoszenia
  5. Bezpieczeństwo hasła
    1. Przechowywanie haseł
    2. Złożoność hasła
    3. Uwierzytelnianie dwuetapowe 2FA
      1. Przykładowy ekran generowania kodu QR dla uwierzytelnienia dwuetapowego
    4. Zmiana hasła przy pierwszym logowaniu
    5. Okresowa zmiana hasła
    6. Proof of Work
    7. Limit szybkości w sesjach sygnalistów
    8. Spowolnienie przy nieudanych próbach logowania
    9. Odzyskiwanie hasła
  6. Odporność na ataki DoS
  7. Szyfrowanie połączeń SMTP za pomocą TLS
  8. Szyfrowanie danych

Architektura

Oprogramowanie skrzynki kontaktowej GlobaLeaks składa się z dwóch głównych komponentów: Backend oraz a Client.

  • Backend to warsta działająca na serwerze fizycznym. Opiera się na oprogramowaniu w języku Python, który udostępnia również API REST dla aplikacji Client.
  • Client to aplikacja internetowa w języku JavaScript, która współdziała z warstwą Backend za pośrednictwem XMLHttpRequest (XHR).

Anonimowość

Anonimowość użytkowników jest chroniona za pomocą technologii Tor. Cała aplikacja stara się uniknąć rejestrowania metadanych, które mogłyby prowadzić do identyfikacji sygnalistów.

Bezpieczeństwo sieci

Anonimowość połączenia

Anonimowość użytkowników jest uzyskiwana dzięki wdrożeniu technologii Tor. Aplikacja implementuje Tor Onion Services v3 i doradza użytkownikom korzystanie z przeglądarki Tor podczas uzyskiwania do niej dostępu.

Szyfrowanie połączenia

  • Połączenie jest zawsze szyfrowane, za pomocą zabezpieczeń sieci Tor podczas korzystania z przeglądarki TorBrowser lub za pomocą TLS, gdy aplikacja jest dostępna za pośrednictwem zwykłej przeglądarki.
  • Korzystanie z protokołu Tor zamiast HTTPS jest zalecane ze względu na jego zaawansowane właściwości odporności na selektywne przechwytywanie i cenzurę, które utrudniałyby osobom trzecim selektywne przechwycenie lub zablokowanie dostępu do witryny konkretnemu sygnalistowi lub działowi firmy.
  • Oprogramowanie umożliwia również łatwą konfigurację protokołu HTTPS oferując zarówno automatyczną konfigurację za pomocą Let’s Encrypt, jak również konfigurację ręczną (własne certyfikaty).
  • Konfiguracja umożliwia stosowanie jedynie wersji TLS1.2+ i jest tak przygotowana, aby osiągnąć klasę A+ SSLLabs.
  • W ramach konfiguracji włączone są jedynie następujące ciphertexts:
    TLS13-AES-256-GCM-SHA384
TLS13-CHACHA20-POLY1305-SHA256
TLS13-AES-128-GCM-SHA256
ECDHE-ECDSA-AES256-GCM-SHA384
ECDHE-RSA-AES256-GCM-SHA384
ECDHE-ECDSA-CHACHA20-POLY1305
ECDHE-RSA-CHACHA20-POLY1305
ECDHE-ECDSA-AES128-GCM-SHA256
ECDHE-RSA-AES128-GCM-SHA256

Uwierzytelnianie

Poufność uwierzytelniania jest chroniona przez Tor Onion Services v3 lub TLS w wersji 1.2+.

Hasło

Aby uzyskać dostęp do skrzynki kontaktowej, użytkownicy w roli Administrator oraz Odbiorca muszą wprowadzić swoją nazwę użytkownika oraz hasło. Jeżeli podane hasło jest prawidłowe, system przyznaje dostęp do funkcjonalności dostępnej dla tego użytkownika.

Kod zgłoszenia

W celu otrzymania dostępu do swojego zgłoszenia, sygnaliści muszą podać swój kod zgłoszenia, który jest losowo generowaną 16-cyfrową sekwencją utworzoną podczas pierwszego przesyłania zgłoszenia. Ten 16-cyfrowy format przypomina standardowy numer telefonu, co ułatwia sygnalistom ukrycie swoich kodów zgłoszeń.

Bezpieczeństwo hasła

Przechowywanie haseł

  • Hasła nigdy nie są przechowywane w postaci zwykłego tekstu, ale system przechowuje tylko hash danego hasła. Dotyczy to każdego tajnego klucza uwierzytelniającego, w tym kodów zgłoszeń sygnalistów informujących o nieprawidłowościach.
  • System przechowuje hasła użytkowników zaszyfrowane losowo 128-bitową salt (solą), unikalną dla każdego użytkownika.
  • Hasła są szyfrowane przy użyciu Argon2, funkcji pochodnej klucza, która została wybrana jako zwycięzca konkursu haszowania haseł w lipcu 2015 r.
  • Hash obejmuje sól na każdego użytkownika oraz systemową sól dla sygnalistów.

Złożoność hasła

System wymusza stosowanie złożonego hasła poprzez implementację niestandardowego algorytmu niezbędnego do zapewnienia rozsądnej entropii każdego kodu uwierzytelniającego.

Hasła są punktowane w trzech poziomach: Silne, Akceptowalne, Niebezpieczne.

  • Silne: silne hasło powinno składać się z wielkich i małych liter, cyfr i symboli, mieć co najmniej 12 znaków i zawierać co najmniej 10 różnych danych wejściowych.
  • Akceptowalne: Akceptowalne hasło powinno składać się z co najmniej 3 różnych danych wejściowych spośród wielkich liter, małych liter, cyfr i symboli, zawierać co najmniej 10 znaków i zawierać co najmniej 7 różnych danych wejściowych.
  • Niebezpieczne: hasło znajdujące się poniżej silnych lub akceptowalnych poziomów jest oznaczane jako niepewne i nie jest akceptowane przez system.

Wskazówka: Zalecamy użytkownikom korzystanie z menedżerów haseł typu KeePassXC do generowania i przechowywania silnych i unikalnych haseł.

Uwierzytelnianie dwuetapowe 2FA

  • System implementuje uwierzytelnianie dwuetapowe (2FA) w oparciu o algorytm RFC 6238 i 160-bitowe kody.
  • Użytkownicy mogą korzystać z 2FA za pomocą własnych preferencji, a administratorzy mogą opcjonalnie wymusić to wymaganie.
Przykładowy ekran generowania kodu QR dla uwierzytelnienia dwuetapowego

Przykładowy ekran generowania kodu QR dla uwierzytelnienia dwuetapowego

Wskazówka: Zalecamy korzystanie z aplikacji FreeOTP dostępnej na platformach Android oraz iOS.

Zmiana hasła przy pierwszym logowaniu

  • System wymusza na użytkownikach zmianę własnego hasła przy pierwszym logowaniu.
  • Administratorzy mogą także wymusić zmianę hasła dla użytkowników przy ich następnym logowaniu.

Okresowa zmiana hasła

  • Domyślnie system wymusza na użytkownikach zmianę własnego hasła przynajmniej raz w roku.
  • Ten okres jest konfigurowany przez administratorów.

Proof of Work

  • System implementuje automatyczny Proof of Work przy każdym logowaniu, który wymaga od każdego klienta zażądania tokena, rozwiązania problemu obliczeniowego, zanim będzie mógł wykonać logowanie lub przesłać plik.
  • Proof of Work jest znanym algorytmem osiągania konsensusu w sieci używającej blockchain. Taki model osiągania konsensusu jest używany np. przy tworzeniu nowych bloków kryptowaluty Bitcoin.

Limit szybkości w sesjach sygnalistów

  • System implementuje ograniczanie szybkości sesji sygnalistów, uniemożliwiając wykonanie więcej niż 5 żądań na sekundę.

Spowolnienie przy nieudanych próbach logowania

  • System identyfikuje wiele nieudanych prób logowania i wdraża procedurę spowolnienia, w której uwierzytelniający uzytkownik powinien czekać do 42 sekund na zakończenie uwierzytelniania.
  • Ta funkcja ma na celu spowolnienie możliwych ataków wymagających więcej zasobów i udaremnienie potencjalnych ataków.

Odzyskiwanie hasła

  • W przypadku utraty hasła użytkownicy mogą poprosić o zresetowanie hasła za pośrednictwem interfejsu logowania.
  • Po rozpoczęciu procedury odzyskiwania hasła użytkownicy są proszeni o wprowadzenie swojej nazwy użytkownika lub adresu e-mail. Jeśli podana nazwa użytkownika lub adres e-mail odpowiada istniejącemu użytkownikowi, system prześle link resetowania hasła na adres e-mail użytkownika.
  • Klikając w link otrzymany w wiadomości e-mail, użytkownik wprowadza nowy adres e-mail, inny niż poprzedni.
  • Użytkownik klikając na link resetujący musi najpierw wprowadzić klucz odzyskiwania konta.
  • W przypadku, gdy dla użytkownika włączona jest funkcja 2FA, użytkownik klikający link resetowania musi najpierw wprowadzić kod uwierzytelniający pobrany z aplikacji 2FA.

Odporność na ataki DoS

Aby uniknąć wyłączenia usługi aplikacji (Dos - Denial of Service) i bazy danych, system ma zaimplementowane następujące mechanizmy:

  • Stara się ograniczyć możliwość zautomatyzowania dowolnej operacji, wymagając interakcji człowieka (np. z wdrożeniem Proof of Work).
  • Zostały ograniczone możliwości wyzwalania procedur intensywnie korzystających z procesora przez użytkownika zewnętrznego (np. poprzez wprowadzenie limitów zapytań i czasu wykonywania zadań).
  • Wdrożono monitorowanie każdej aktywności, próbując przy tym wykrywać ataki i proaktywnie uruchamiać środki bezpieczeństwa, aby zapobiec DoS (np. spowolnienie na szybkich operacjach).

Szyfrowanie połączeń SMTP za pomocą TLS

  • Wszystkie powiadomienia są wysyłane przez SMTP przez szyfrowany kanał TLS przy użyciu SMTP/TLS lub SMTPS, w zależności od konfiguracji.
  • Odbiorca ma także możliwość użycia własnego klucza PGP, dzięki czemu powiadomienia e-mail wysyłane przez system są szyfrowane tym kluczem.

Szyfrowanie danych

O nieco innym zagadnieniu, a mianowicie o bezpieczeństwie i szyfrowaniu przechowywanych danych można przeczytać w sekcji Szyfrowanie.