Przejdź do treści
Załóż bezpłatne konto
Załóż bezpłatne konto

Jak bezpieczne jest Crunu?

Budujemy Crunu przy założeniu, że jego serwer zostanie zaatakowany. Poniżej opisujemy, co dostaje każdy atakujący z modelu zagrożeń produktu, czego nie dostaje i która warstwa stoi mu na drodze – także tam, gdzie Crunu nie może pomóc.

Załóż bezpłatne kontoPoznaj model bezpieczeństwa
  • AES-256-GCM szyfruje każdą wersję
  • X25519 szyfruje klucze dla odbiorców, Ed25519 podpisuje
  • Klucz konta powstaje z twojego hasła (PBKDF2-SHA256, 1 000 000 iteracji) i Secret Key o długości około 128 bitów; żadne z nich nie trafia na serwer
  • Na żadnym etapie serwer nie ma klucza do odszyfrowania

Trzy warstwy ochrony i wydania, które możesz sprawdzić

Model zagrożeń Crunu przypisuje każde zabezpieczenie do warstwy, która je zapewnia. Ma to największe znaczenie, gdy atakującym jest sam serwer, bo wtedy działają dalej tylko niektóre warstwy.

  • Kryptografia

    Kto ma klucz

    Klucze środowisk są szyfrowane tylko dla osób, maszyn i tokenów, którym na to pozwolisz, a listy dostępu i wersje są podpisane. Bez klucza szyfrogram pozostaje szyfrogramem.

    Jeśli serwer zostanie przejętyDziała dalej.

  • Serwer

    Komu wysyła zaszyfrowane dane i czyje zmiany przyjmuje

    Limity logowania, wygasanie sesji, reguły sieciowe, okres oczekiwania kodu odzyskiwania i odcięcie usuniętych osób.

    Jeśli serwer zostanie przejętyPrzestaje działać.

  • Klient

    Co sprawdzają twoja przeglądarka i agent

    Podpisy, numery wersji i odciski kluczy: urządzenia odrzucają wszystko, co niepodpisane albo starsze od tego, co już widziały. Ukrywanie wartości na ekranie to też reguła klienta i chroni przed wpadką, a nie przed skopiowaniem.

    Jeśli serwer zostanie przejętyDziała dalej, chyba że serwer wyśle zmodyfikowaną stronę internetową.

  • Weryfikowalne wydania

    Czy kod, który uruchamiasz, jest oryginalny

    Każde wydanie agenta i aplikacji webowej jest podpisane kluczem Ed25519. Kompilacja aplikacji webowej jest odtwarzalna, a strona nie dopuszcza skryptów zewnętrznych.

    Jeśli serwer zostanie przejętyAgent nadal sprawdza swoje aktualizacje. Aplikacja webowa sprawdza się wewnątrz strony, którą sprawdza, więc nie wykryje serwera, który zmienia jedno i drugie.

Przykład. Kiteline to fikcyjna firma.

Atak po ataku

Jedna karta na każdego atakującego z modelu zagrożeń Crunu. Ocena dotyczy wartości w twoich środowiskach; wszystko inne, co dostaje atakujący, wymienia karta.

  • ChronioneTwoje wartości pozostają nieczytelne i niezmienione.
  • OgraniczoneAtakujący dostaje coś realnego, a karta to wymienia.
  • Bez ochronyCrunu tego nie powstrzyma. Karta mówi, co pomaga.

  1. Wycieka kopia bazy danych

    Chronione

    Wyciek kopii zapasowej, skradziony dysk, włamanie do innej usługi albo firma hostingowa działająca w złej wierze.

    Co dostaje

    • Zaszyfrowane dane każdego środowiska, klucze publiczne i podpisane rekordy
    • Metadane: nazwy projektów i środowisk, skład zespołu i to, jak często coś się zmienia
    • Tokeny, ale tylko jako skróty z kluczem (HMAC)

    Czego nie dostaje

    • Twoich wartości: w kopii nigdzie nie ma klucza do odszyfrowania
    • Drogi na skróty do twojego hasła: każda próba wymaga też twojego Secret Key, którego nigdy nie było na serwerze, więc sprawdzenie jednej próby oznacza przeszukanie około 2¹²⁸ możliwości
    • Działających tokenów: klucza do tych skrótów nie ma w bazie danych

    Nie umieszczaj sekretów w nazwach: projekt nazwany od nieogłoszonej transakcji zdradza ją każdemu, kto czyta kopię.

    ChroniKryptografiaSerwer

  2. Ktoś przejmuje serwer

    Ograniczone

    Kontrola nad jego kodem i bazą danych: intruz, nieuczciwy operator albo przejęte konto w chmurze. Na app.crunu.com ten serwer prowadzi Crunu, a na własnym serwerze – ty.

    Co dostaje

    • Wszystko, co jest w kopii bazy danych, a do tego to, kto pobrał którą wersję i kiedy
    • Możliwość odmowy usługi albo zgubienia twoich zmian
    • Okazję, by wysłać zmodyfikowaną stronę, która przechwyci twoje hasło i Secret Key, gdy się logujesz. To główne pozostałe ryzyko.

    Czego nie dostaje

    • Miejsca wśród odbiorców: klucze środowisk są szyfrowane tylko dla kluczy certyfikowanych przez twoją organizację, a twoje urządzenia sprawdzają podpisaną listę dostępu
    • Podmiany klucza ani zmiany danych: klucze są zapisane w podpisanych rekordach, a każda wersja jest podpisana i powiązana ze swoim środowiskiem i numerem
    • Niepostrzeżonego cofnięcia stanu na urządzeniu, które widziało nowsze dane. Urządzenie, które nigdy ich nie widziało, tego nie rozpozna.

    Aplikacja przy każdym ładowaniu sprawdza się względem podpisanego manifestu Crunu, a strona nie dopuszcza skryptów zewnętrznych. To sprawdzenie działa w tej samej stronie, więc nie wykryje serwera, który zmienia jedno i drugie.

    ChroniKryptografiaKlient

  3. Ktoś przechwytuje połączenie

    Ograniczone

    Sfałszowany certyfikat TLS albo złośliwy serwer proxy między twoim urządzeniem a serwerem.

    Co dostaje

    • To, co serwer widzi w tym połączeniu: zaszyfrowane dane i metadane
    • Tę samą okazję co przejęty serwer, by wysłać zmodyfikowaną stronę

    Czego nie dostaje

    • Twojego hasła ani Secret Key: żadne z nich w żadnej postaci nie przechodzi przez sieć
    • Logowania, które można powtórzyć: każdy podpis logowania zawiera adres serwera i jednorazową wartość (nonce), więc działa raz i tylko na tym serwerze

    ChroniKryptografiaKlient

  4. Ktoś z zespołu odchodzi w konflikcie

    Ograniczone

    Osoba usunięta z organizacji, która zachowała wszystko, co mogła.

    Co dostaje

    • Wszystko, co ta osoba widziała przed usunięciem. Te wartości działają u twoich dostawców, dopóki nie wygenerujesz ich ponownie.

    Czego nie dostaje

    • Niczego więcej z serwera: serwer od razu przestaje tę osobę obsługiwać
    • Nowych wersji: każdy klucz środowiska, który ta osoba miała, zostaje wymieniony, więc jej stare klucze nie otworzą niczego nowego, nawet ze skradzionymi zaszyfrowanymi danymi

    Raport ekspozycji pokazuje, które wersje ta osoba otrzymała, a lista kontrolna wymienia wartości do ponownego wygenerowania u każdego dostawcy.

    ChroniSerwerKryptografia

  5. Ktoś z zespołu zagląda poza swoją rolę

    Chronione

    Uczciwy, ale ciekawski członek zespołu: programista z dostępem do development albo osoba z rolą Operator, która konfiguruje maszyny.

    Co dostaje

    • Środowiska przyznane tej osobie, które może skopiować. Ukrywanie wartości w aplikacji to sposób wyświetlania, a nie szyfrowanie.

    Czego nie dostaje

    • Środowiska production przy dostępie do development: nie ma jego klucza
    • Żadnych wartości z rolą Operator: osoby z tą rolą nie mają żadnego klucza środowiska
    • Innych plików z rolą Specific files: dostaje zaszyfrowaną kopię tylko wybranych plików

    ChroniKryptografia

  6. Ktoś kradnie token sesji

    Ograniczone

    Skopiowany z pamięci przeglądarki albo z dziennika serwera proxy.

    Co dostaje

    • To, na co serwer pozwala temu kontu do końca sesji: po 12 godzinach bez aktywności albo najpóźniej po 7 dniach

    Czego nie dostaje

    • Twoich wartości: do ich odszyfrowania potrzebne są klucze, których token nie zawiera
    • Podpisanych zmian: lista dostępu albo wersja wymaga twojego klucza podpisu
    • Kontroli nad twoim kontem: zmiana hasła lub Secret Key wymaga podania obu

    Twoje konto pokazuje każde urządzenie i każdą sesję, a ty możesz zakończyć jedną z nich albo wszystkie.

    ChroniSerwerKryptografia

  7. Ktoś kradnie twój laptop

    Ograniczone

    Urządzenie, na którym logujesz się do Crunu, zabrane z otwartą albo zablokowaną aplikacją.

    Co dostaje

    • Twój Secret Key, który przeglądarka domyślnie przechowuje, więc barierą zostaje twoje hasło
    • To, co jest otwarte, dopóki aplikacja się nie zablokuje po 10 minutach bez aktywności (domyślnie)

    Czego nie dostaje

    • Twoich kluczy po zablokowaniu aplikacji: bez twojego hasła pozostają zaszyfrowane
    • Twojego konta: otwarta sesja nie zmieni hasła, Secret Key ani kluczy konta

    Z innego urządzenia usuń skradzione albo użyj Device compromised: wymienia klucze twojego konta i rotuje każde środowisko, do którego twoje konto miało klucz.

    ChroniKryptografiaSerwer

  8. Ktoś zdobywa roota na maszynie z agentem

    Ograniczone

    Serwer, na którym działa agent crunu, jest uprawnionym odbiorcą, a więc jest nim też każdy, kto go kontroluje.

    Co dostaje

    • Wszystko, co dostarczono na tę maszynę. Działający już program zachowuje swoje zmienne do ponownego uruchomienia.

    Czego nie dostaje

    • Innych maszyn ani środowisk: każda maszyna ma własne klucze i dostaje tylko to, co jej przyznano
    • Długotrwałego dostępu: dzierżawa kończy się po 24 godzinach bez kontaktu, a maszyna, której odebrano dostęp, usuwa swoje środowiska w ciągu kilku minut, jeśli jest online

    ChroniKryptografiaSerwer

  9. Wycieka kod rejestracji

    Chronione

    Jednorazowy kod, który podajesz poleceniu crunu enroll na nowej maszynie.

    Co dostaje

    • Szansę na zarejestrowanie własnej maszyny, jeśli użyje kodu przed twoją maszyną

    Czego nie dostaje

    • Zatwierdzenia: administrator zatwierdza maszynę dopiero po porównaniu odcisku klucza, który crunu enroll wypisuje na prawdziwej maszynie
    • Niepostrzeżonej drugiej próby: kod domyślnie działa 15 minut, traci ważność przy pierwszym użyciu, a ponowne użycie kodu wywołuje alert

    ChroniKryptografiaSerwer

  10. Wycieka token CI

    Ograniczone

    Token usługowy skopiowany z magazynu sekretów potoku CI.

    Co dostaje

    • Dokładnie to, co przyznano tokenowi, często jedno środowisko, dopóki go nie unieważnisz albo token nie wygaśnie

    Czego nie dostaje

    • Żadnego innego środowiska: klucz production nigdy nie jest szyfrowany dla tokenu, któremu nie przyznano production
    • Logowania z innego miejsca, jeśli token ma powiązanie OIDC: bez tokenu twojego dostawcy CI dla właściwego repozytorium i gałęzi nie wejdzie

    ChroniKryptografiaSerwer

  11. Ktoś zgaduje hasła przy logowaniu

    Chronione

    Próby logowania z jednego adresu albo rozłożone na wiele adresów.

    Co dostaje

    • 10 nieudanych prób na adres IP i 5 na konto co 15 minut

    Czego nie dostaje

    • Wskazówki, że konto istnieje: nieznany e-mail i błędne hasło dostają tę samą odpowiedź
    • Wejścia z samym hasłem: logowanie wymaga też twojego Secret Key, a nowe urządzenie – twojego drugiego składnika, gdy go włączysz
    • Drogi na skróty przez kody i linki: mają co najmniej 128 losowych bitów i są przechowywane jako skróty z kluczem

    ChroniSerwerKryptografia

  12. Ktoś modyfikuje wydanie agenta

    Chronione

    Zmodyfikowany plik wykonywalny crunu albo skrypt instalacyjny.

    Co dostaje

    • Drogę do środka tylko wtedy, gdy kontroluje też aplikację webową, która pokazuje twoje polecenie instalacji, jak przy przejęciu serwera

    Czego nie dostaje

    • Niepostrzeżonej instalacji: polecenie instalacji w aplikacji webowej zawiera sumy kontrolne SHA-256 z manifestu wydania, a aplikacja webowa sprawdza podpis Ed25519 tego manifestu
    • Niepostrzeżonej aktualizacji: crunu self-update sprawdza podpis wydania kluczem wbudowanym w agenta

    ChroniKryptografiaKlient

  13. Na twoim urządzeniu działa złośliwe oprogramowanie

    Bez ochrony

    Keylogger, złośliwe rozszerzenie przeglądarki albo ktoś z uprawnieniami roota na twoim komputerze.

    Co dostaje

    • Twoje hasło i Secret Key w chwili wpisywania oraz wszystko, co to urządzenie odszyfrowuje

    Czego nie dostaje

    • Środowisk, których twoje konto nie może otworzyć

    Żadne szyfrowanie nie ochroni urządzenia przed nim samym. Używaj urządzeń, które kontrolujesz, a po przejęciu użyj Device compromised z czystego urządzenia i wygeneruj ponownie wartości, do których miało dostęp przejęte urządzenie.

    ChroniNic w Crunu

Każde znane ograniczenie i co z nim zrobić

Kryptografia

Standardowe elementy w dwóch implementacjach: wbudowane w przeglądarkę WebCrypto i biblioteka standardowa Go w agencie. Obie są testowane na tych samych wspólnych wektorach testowych.

Kryptografia
AlgorytmCo robi w CrunuGdzie działa
AES-256-GCMSzyfruje każdą wersję środowiska. Dodatkowe dane uwierzytelniane (AAD) wiążą szyfrogram z jego organizacją, środowiskiem i numerem wersji, więc nie da się go podać za inny.Przeglądarka i agent
X25519Szyfruje klucz środowiska dla jednego odbiorcy: osoby, maszyny albo tokenu usługowego. Każda zaszyfrowana kopia używa nowej pary kluczy.Przeglądarka i agent
Ed25519Podpisuje listy dostępu, wersje, linki dostępu i wydania. Urządzenia sprawdzają każdy podpis, zanim zaufają rekordowi.Przeglądarka i agent; wydania podpisuje Crunu
HKDF-SHA256Wyprowadza z jednego sekretu osobny klucz do każdego zadania, więc żaden klucz nie służy dwóm celom.Przeglądarka, agent i serwer
PBKDF2-SHA256, 1 000 000 iteracji i Secret KeyZamienia twoje hasło w jedną połowę klucza konta. Drugą połową jest twój Secret Key, około 128 losowych bitów. Żadne z nich nie opuszcza twojego urządzenia.Twoja przeglądarka albo crunu w terminalu
SHA-256Łączy wpisy dziennika audytu w łańcuch skrótów i tworzy odciski kluczy, które można porównać wzrokiem.Łańcuch zapisuje serwer; twoja przeglądarka i twoje własne narzędzia mogą go przeliczyć
Dopełnienie do 4096 bajtówZaokrągla każdą zaszyfrowaną wersję w górę do pełnych bloków 4 KB, żeby nie było widać jej dokładnego rozmiaru.Przeglądarka i agent, przed szyfrowaniem
  • Osobny klucz dla każdego środowiska. Dostęp do development nie otwiera niczego w production. Każda osoba, maszyna i każdy token dostaje własną zaszyfrowaną kopię tylko tych kluczy, do których ma prawo.
  • Każdy format ma swoją wersję. Każdy rekord podaje wersję swojego formatu ("v": 2), a wyprowadzanie klucza ma własną (kdf.v). Urządzenia odrzucają nieznane wersje, więc serwer nie może obniżyć kosztu zgadywania twojego hasła ani podsunąć starszego formatu.

Komputery kwantowe

Wystarczająco duży komputer kwantowy złamałby część tych elementów, a innym ledwie by zaszkodził. Dziś taki komputer nie istnieje. Tak wygląda sytuacja Crunu – bez zgadywania, kiedy mógłby powstać.

Komputery kwantowe
AlgorytmAtak kwantowyCo oznaczałby dla Crunu
AES-256-GCMAlgorytm Grovera: szybsze szukanie kluczaZostaje około 128 bitów bezpieczeństwa. NIST oczekuje, że AES-256 pozostanie bezpieczny przez bardzo długi czas.
SHA-256 i HMACPrzeszukiwanie metodą GroveraŁańcuch skrótów dziennika audytu i skróty z kluczem zachowują duży zapas. NIST używa SHA-256 jako punktu odniesienia dla swoich poziomów bezpieczeństwa postkwantowego.
PBKDF2 i Secret KeyPrzeszukiwanie metodą Grovera; algorytm Shora nie ma tu zastosowaniaZgadywanie nadal wymaga 128 losowych bitów Secret Key – to rozmiar klucza AES-128, który według przewidywań NIST pozostanie bezpieczny przez dziesięciolecia. Ani hasło, ani Secret Key nie trafiają na serwer.
X25519Algorytm Shora: klucz prywatny z klucza publicznegoZłamany. Zaszyfrowane nim klucze środowisk dałoby się otworzyć.
Ed25519Algorytm ShoraZłamany. Podpisy dałoby się fałszować, ale tylko w chwili ataku. Wcześniejsze dane nie zostają ujawnione.

Zbierz teraz, odszyfruj później

Każdy klucz środowiska jest szyfrowany kluczami publicznymi X25519 jego odbiorców, a zaszyfrowane kopie leżą na serwerze obok tych kluczy publicznych. Ktoś, kto zachowa kopię bazy danych, mógłby – gdy powstanie duży komputer kwantowy – otworzyć te kopie i odczytać wersje zapisane w tej kopii bazy. NIST nazywa to zagrożenie „harvest now, decrypt later”, czyli „zbierz teraz, odszyfruj później”.

Sięga ono tylko tego, co jest w tej kopii. Wersji zapisanych po jej wykonaniu w niej nie ma, a dane dostępowe wygenerowane ponownie u dostawcy są bezwartościowe dla kogoś, kto odszyfruje stare.

Twoje hasło, Secret Key i klucz konta nie są w ten sposób narażone: nigdy nie trafiają na serwer i używa się na nich wyłącznie funkcji symetrycznych. Ten atak też ich nie potrzebuje, bo celuje bezpośrednio w klucze X25519.

Podpisy

Podpisy Ed25519 chronią listy dostępu, wersje i wydania. Komputer kwantowy pozwoliłby fałszować nowe podpisy, ale fałszerstwo ma znaczenie tylko wtedy, gdy zostanie wykonane i przyjęte, więc to ryzyko na dzień, w którym taki komputer powstanie, a nie dla danych zapisanych dziś. NIST zwraca uwagę na to samo: podpisom nie grozi atak „zbierz teraz, odszyfruj później”.

Czego Crunu używa dziś i co dalej

Crunu nie używa dziś algorytmów postkwantowych. NIST opublikował pierwsze standardy postkwantowe w sierpniu 2024: ML-KEM do ustalania kluczy (FIPS 203) i ML-DSA do podpisów (FIPS 204). Jego plan przejścia, sfinalizowany w październiku 2026, wymienia uzgadnianie kluczy na krzywych eliptycznych i EdDSA wśród algorytmów, które po 2030 roku uzna za przestarzałe, a po 2035 roku przestanie dopuszczać w standardach NIST.

Przejście na kryptografię postkwantową jest w planie rozwoju Crunu. Nie ogłaszamy algorytmów ani terminów, do których nie możemy się jeszcze zobowiązać: gdy kryptografia Crunu się zmieni, napiszemy o tym na tej stronie.

Co możesz zrobić już teraz

  • Zastanów się, jak długo każdy sekret zachowuje wartość. Klucz, który generujesz ponownie co kilka miesięcy, niewiele traci przez kopię odszyfrowaną po latach; długoterminowe dane dostępowe konta root tracą więcej.
  • Generuj ponownie długoterminowe wartości u ich dostawców według harmonogramu i zapisuj każdą nową wartość jako nową wersję.
  • Jeśli martwi cię kopia bazy danych w cudzych rękach, prowadź własny serwer. Baza danych i jej kopie zapasowe zostają wtedy u ciebie.

Źródła

  1. NIST: NIST Releases First 3 Finalized Post-Quantum Encryption Standards (August 13, 2024)
  2. NIST FIPS 203: Module-Lattice-Based Key-Encapsulation Mechanism Standard (August 2024)
  3. NIST FIPS 204: Module-Lattice-Based Digital Signature Standard (August 2024)
  4. NIST IR 8547: Transition to Post-Quantum Cryptography Standards (October 2026)
  5. NIST: Post-Quantum Cryptography FAQs (AES and Grover’s algorithm)
  6. L. K. Grover: A fast quantum mechanical algorithm for database search (1996)
  7. P. W. Shor: Polynomial-Time Algorithms for Prime Factorization and Discrete Logarithms on a Quantum Computer (1997)

Sprawdzono 28 października 2026.

Sprawdź samodzielnie

Nie mamy jeszcze odznak ani certyfikatów do pokazania. Poniżej to, co możesz sprawdzić już dziś, i to, czego brakuje.

  • Podpisane wydania.Każde wydanie agenta i aplikacji webowej jest podpisane kluczem wydania Ed25519. crunu self-update sprawdza podpis kluczem wbudowanym w agenta, a aplikacja webowa pokazuje Signed build, gdy sprawdzi się względem podpisanego manifestu.
  • Odtwarzalna kompilacja aplikacji webowej.Jeden commit źródeł zawsze daje te same pliki, bajt w bajt. Kod źródłowy nie jest publikowany, więc dziś tylko Crunu może ponownie zbudować wydanie i je porównać.
  • Brak skryptów zewnętrznych.Polityka bezpieczeństwa treści strony (CSP) dopuszcza tylko własny kod Crunu, ładowany z sumami kontrolnymi integralności (SRI).
  • Mało zależności.Agent używa tylko biblioteki standardowej Go, a kod przeglądarki zawiera jeden pakiet npm, yaml.
  • Dziennik audytu, który sprawdzisz poza Crunu.Właściciele i administratorzy mogą wyeksportować dziennik do JSONL i przeliczyć jego łańcuch skrótów SHA-256 własnymi narzędziami.
  • Czego brakuje.Nie ma zewnętrznego audytu bezpieczeństwa, certyfikatu SOC 2 ani ISO 27001, nie ma też opublikowanego kodu źródłowego. Crunu jest we wczesnym dostępie; Audyty i dokumenty wymieniają dokumenty, które mamy.
  • Chcesz zgłosić problem?Napisz na security@crunu.com. Ten sam kontakt jest w naszym pliku security.txt, a Znane ograniczenia wymieniają każde ograniczenie, o którym już wiemy.
Przykład. Kiteline to fikcyjna firma.

Pytania o bezpieczeństwo Crunu

Czy Crunu może odczytać moje sekrety?

Nie. Serwer – prowadzony przez Crunu na app.crunu.com albo przez ciebie we własnym hostingu – przechowuje tylko zaszyfrowane dane i nie ma klucza, który mógłby je odszyfrować. Widzi natomiast metadane: nazwy, adresy e-mail, dziennik audytu i to, kiedy zapisano każdą wersję. Dotarcie do twoich wartości wymagałoby zmiany kodu na twoim urządzeniu, na przykład zmodyfikowanej strony internetowej – to główne pozostałe ryzyko opisane na tej stronie.

Co się stanie, jeśli ktoś włamie się na wasz serwer?

Kto się włamie, dostaje zaszyfrowane dane, klucze publiczne, skróty tokenów z kluczem i metadane. Nie odszyfruje twoich wartości, nie dopisze się do listy dostępu ani nie zmieni wersji tak, żeby twoje urządzenia tego nie zauważyły. Może odciąć cię od usługi albo wysłać zmodyfikowaną stronę. Jeśli dojdzie do włamania do app.crunu.com, bez zbędnej zwłoki wyślemy e-mail do właścicieli kont, których to dotyczy.

Co, jeśli zapomnę hasła?

Nikt nie może go zresetować, łącznie z nami, bo nigdy nie dostajemy twojego hasła ani Secret Key. Wrócić do konta pozwalają wydrukowany Emergency Kit i kod odzyskiwania. Jeśli stracisz je wszystkie, twojego konta nie da się otworzyć, choć właściciele i administratorzy nadal mogą otworzyć wspólne środowiska organizacji.

Czy Crunu chroni przed komputerami kwantowymi?

Częściowo. Oczekuje się, że AES-256 i SHA-256 się utrzymają. X25519 i Ed25519 nie oparłyby się dużemu komputerowi kwantowemu, który dziś nie istnieje. Crunu nie używa dziś algorytmów postkwantowych, więc kopia bazy danych przechowywana latami mogłaby kiedyś ujawnić zapisane w niej wersje. Przejście na kryptografię postkwantową jest w planie rozwoju Crunu.

Czy Crunu przeszło audyt?

Nie. Crunu jest we wczesnym dostępie, nie ma certyfikatu SOC 2 ani ISO 27001 i nie opublikowano żadnego zewnętrznego audytu bezpieczeństwa. Kod źródłowy też nie jest publikowany. To, co możesz sprawdzić już dziś, opisuje część „Sprawdź samodzielnie” powyżej.

Czy własny serwer jest bezpieczniejszy niż app.crunu.com?

Zmienia to, komu ufasz, a nie szyfrowanie. Własny serwer trzyma bazę danych i jej kopie zapasowe u ciebie i wysyła stronę z infrastruktury, którą kontrolujesz. W zamian kopie zapasowe, aktualizacje i własny sekret serwera stają się twoim zadaniem. Serwer udostępniamy na prośbę: napisz na support@crunu.com.

Jak zgłosić podatność?

Napisz na security@crunu.com, opisz kroki, które odtwarzają problem, i nie umieszczaj w zgłoszeniu prawdziwych sekretów. Ten sam kontakt jest w naszym pliku security.txt, a strona „Model bezpieczeństwa” podaje zasady testowania.

Trzymaj sekrety zespołu na serwerze, który nie może ich odczytać

Załóż konto na app.crunu.com. Twoje klucze są tworzone w twojej przeglądarce, a serwer dostaje tylko zaszyfrowane dane.

Bezpłatnie we wczesnym dostępie. Poznaj model bezpieczeństwa