Zum Inhalt springen
Kostenlos registrieren
Kostenlos registrieren

Wie sicher ist Crunu?

Wir bauen Crunu unter der Annahme, dass sein Server angegriffen wird. Für jeden Angriff aus dem Bedrohungsmodell des Produkts steht hier, was Angreifer damit bekommen, was nicht und welche Schutzebene im Weg steht, auch dort, wo Crunu nicht helfen kann.

Kostenlos registrierenZum Sicherheitsmodell
  • AES-256-GCM verschlüsselt jede Version
  • X25519 versiegelt Schlüssel, Ed25519 signiert
  • Kontoschlüssel aus Ihrem Passwort (PBKDF2-SHA256, 1.000.000 Iterationen) und einem Secret Key mit etwa 128 Bit; keines von beiden geht an den Server
  • Kein Schlüssel zum Entschlüsseln auf dem Server, in keinem Schritt

Drei Schutzebenen und Releases, die Sie prüfen können

Das Bedrohungsmodell von Crunu ordnet jeden Schutz der Ebene zu, die ihn liefert. Das zählt vor allem, wenn der Server selbst der Angreifer ist, denn dann wirken nur manche Ebenen weiter.

  • Kryptografie

    Wer den Schlüssel hat

    Umgebungsschlüssel werden nur für die Personen, Maschinen und Tokens versiegelt, die Sie zulassen, und Zugriffslisten und Versionen sind signiert. Ohne den Schlüssel bleibt Chiffretext Chiffretext.

    Wenn der Server übernommen istWirkt weiter.

  • Server

    An wen er Chiffretext ausliefert und wessen Änderungen er annimmt

    Anmeldelimits, Ablauf von Sitzungen, Netzwerkregeln, die Wartezeit des Wiederherstellungscodes und das Abschneiden von Personen, die Sie entfernt haben.

    Wenn der Server übernommen istWirkt nicht mehr.

  • Client

    Was Ihr Browser und der Agent prüfen

    Signaturen, Versionsnummern und Fingerabdrücke: Geräte lehnen alles ab, was unsigniert oder älter ist als das, was sie schon gesehen haben. Auch das Verbergen von Werten auf dem Bildschirm ist eine Regel des Clients. Sie verhindert Versehen, kein Kopieren.

    Wenn der Server übernommen istWirkt weiter, es sei denn, der Server sendet eine manipulierte Webseite.

  • Prüfbare Releases

    Ob der Code, den Sie ausführen, echt ist

    Jedes Release des Agenten und der Web-App ist mit Ed25519 signiert. Der Web-Build ist reproduzierbar, und die Seite erlaubt keine Skripte von Dritten.

    Wenn der Server übernommen istUpdates des Agenten prüfen weiter. Die Web-App prüft sich innerhalb der Seite, die sie prüft, und erkennt deshalb keinen Server, der beides verändert.

Beispiel. Kiteline ist ein fiktives Unternehmen.

Angriff für Angriff

Eine Karte für jeden Angreifer aus dem Bedrohungsmodell von Crunu. Die Bewertung bezieht sich auf die Werte in Ihren Umgebungen. Alles andere, was ein Angreifer bekommt, steht auf der Karte.

  • GeschütztIhre Werte bleiben unlesbar und unverändert.
  • EingeschränktAngreifer bekommen etwas Echtes, und die Karte nennt es.
  • Nicht geschütztCrunu kann es nicht verhindern. Die Karte sagt, was hilft.

  1. Eine Kopie der Datenbank gelangt nach außen

    Geschützt

    Ein geleaktes Backup, eine gestohlene Festplatte, ein Einbruch bei einem anderen Dienst oder ein Hosting-Anbieter, der böswillig handelt.

    Angreifer bekommen

    • Chiffretext jeder Umgebung, öffentliche Schlüssel und signierte Datensätze
    • Metadaten: Namen von Projekten und Umgebungen, wer zum Team gehört und wie oft sich etwas ändert
    • Tokens, aber nur als Hashes mit geheimem Schlüssel (HMAC)

    Angreifer bekommen nicht

    • Ihre Werte: Darin steckt nirgends ein Schlüssel zum Entschlüsseln
    • Eine Abkürzung zu Ihrem Passwort: Jeder Rateversuch braucht zusätzlich Ihren Secret Key, der nie auf dem Server war, und einen einzigen Versuch zu prüfen heißt deshalb, etwa 2¹²⁸ Möglichkeiten zu durchsuchen
    • Funktionierende Tokens: Der Schlüssel zu diesen Hashes liegt nicht in der Datenbank

    Halten Sie Secrets aus Namen heraus: Ein Projekt, das nach einem unangekündigten Deal benannt ist, verrät den Deal allen, die die Kopie lesen.

    Geschützt durchKryptografieServer

  2. Jemand übernimmt den Server

    Eingeschränkt

    Kontrolle über seinen Code und seine Datenbank: durch einen Eindringling, einen böswilligen Betreiber oder ein gekapertes Cloud-Konto. Auf app.crunu.com betreibt Crunu diesen Server, auf Ihrem eigenen Server tun Sie es.

    Angreifer bekommen

    • Alles aus einer Datenbankkopie, dazu, wer welche Version wann heruntergeladen hat
    • Die Möglichkeit, den Dienst zu verweigern oder Ihre Änderungen zu verwerfen
    • Die Gelegenheit, eine manipulierte Webseite zu senden, die Ihr Passwort und Ihren Secret Key bei der Anmeldung abgreift. Das ist das größte verbleibende Risiko.

    Angreifer bekommen nicht

    • Einen Platz unter den Empfängern: Umgebungsschlüssel werden nur für Schlüssel versiegelt, die Ihre Organisation zertifiziert hat, und Ihre Geräte prüfen die signierte Zugriffsliste
    • Einen ausgetauschten Schlüssel oder veränderte Daten: Schlüssel sind in signierten Datensätzen festgeschrieben, und jede Version ist signiert und an ihre Umgebung und Nummer gebunden
    • Einen unbemerkten Rollback auf einem Gerät, das neuere Daten gesehen hat. Ein Gerät, das sie nie gesehen hat, kann ihn nicht erkennen.

    Die App prüft sich bei jedem Laden gegen das signierte Manifest von Crunu, und die Seite erlaubt keine Skripte von Dritten. Diese Prüfung läuft in derselben Seite und erkennt deshalb keinen Server, der beides verändert.

    Geschützt durchKryptografieClient

  3. Jemand fängt die Verbindung ab

    Eingeschränkt

    Ein gefälschtes TLS-Zertifikat oder ein bösartiger Proxy zwischen Ihrem Gerät und dem Server.

    Angreifer bekommen

    • Was der Server auf dieser Verbindung sieht: Chiffretext und Metadaten
    • Dieselbe Gelegenheit wie ein übernommener Server, eine manipulierte Webseite zu senden

    Angreifer bekommen nicht

    • Ihr Passwort oder Ihren Secret Key: Keines von beiden geht in irgendeiner Form über das Netz
    • Eine Anmeldung zum Wiederholen: Jede Anmeldesignatur enthält die Adresse des Servers und einen Einmalwert (Nonce) und funktioniert deshalb nur einmal und nur auf diesem Server

    Geschützt durchKryptografieClient

  4. Ein Teammitglied geht im Streit

    Eingeschränkt

    Jemand, den Sie aus der Organisation entfernt haben und der alles behalten hat, was möglich war.

    Angreifer bekommen

    • Alles, was die Person gesehen hat, bevor Sie sie entfernt haben. Diese Werte funktionieren bei Ihren Anbietern weiter, bis Sie sie neu ausstellen.

    Angreifer bekommen nicht

    • Weiteres vom Server: Er liefert der Person sofort nichts mehr aus
    • Neue Versionen: Jeder Umgebungsschlüssel, den die Person hatte, wird rotiert, sodass ihre alten Schlüssel nichts Neues öffnen, auch nicht mit gestohlenem Chiffretext

    Der Offenlegungsbericht zeigt, welche Versionen die Person erhalten hat, und die Checkliste für Neuausstellungen listet die Werte auf, die bei jedem Anbieter zu ändern sind.

    Geschützt durchServerKryptografie

  5. Ein Teammitglied will mehr sehen, als seine Rolle erlaubt

    Geschützt

    Ein ehrliches, aber neugieriges Mitglied: jemand aus der Entwicklung mit Zugriff auf development oder eine Person mit der Rolle Operator, die Maschinen einrichtet.

    Angreifer bekommen

    • Die freigegebenen Umgebungen, und die lassen sich kopieren. Werte in der App zu verbergen ist eine Frage der Anzeige, keine Verschlüsselung.

    Angreifer bekommen nicht

    • Die Umgebung production über einen Zugriff auf development: Deren Schlüssel fehlt
    • Irgendwelche Werte mit der Rolle Operator: Personen mit dieser Rolle besitzen überhaupt keinen Umgebungsschlüssel
    • Andere Dateien mit der Rolle Specific files: Diese Rolle erhält eine versiegelte Kopie nur der ausgewählten Dateien

    Geschützt durchKryptografie

  6. Ein Sitzungstoken wird gestohlen

    Eingeschränkt

    Kopiert aus dem Speicher des Browsers oder aus dem Log eines Proxys.

    Angreifer bekommen

    • Was der Server diesem Konto erlaubt, bis die Sitzung endet: nach 12 Stunden ohne Aktivität, spätestens nach 7 Tagen

    Angreifer bekommen nicht

    • Ihre Werte: Zum Entschlüsseln braucht es Schlüssel, die das Token nicht enthält
    • Signierte Änderungen: Eine Zugriffsliste oder eine Version braucht Ihren Signaturschlüssel
    • Die Kontrolle über Ihr Konto: Um Ihr Passwort oder Ihren Secret Key zu ändern, braucht es beide

    Ihr Konto listet jedes Gerät und jede Sitzung auf, und Sie können eine davon oder alle beenden.

    Geschützt durchServerKryptografie

  7. Ihr Laptop wird gestohlen

    Eingeschränkt

    Ein Gerät, auf dem Sie angemeldet waren, entwendet bei geöffneter oder gesperrter App.

    Angreifer bekommen

    • Ihren Secret Key, den der Browser standardmäßig speichert, sodass Ihr Passwort die verbleibende Hürde ist
    • Alles, was geöffnet ist, bis die App nach 10 Minuten ohne Aktivität sperrt (Voreinstellung)

    Angreifer bekommen nicht

    • Ihre Schlüssel, sobald die App gesperrt ist: Ohne Ihr Passwort bleiben sie verschlüsselt
    • Ihr Konto: Eine offene Sitzung kann weder Ihr Passwort noch Ihren Secret Key oder Ihre Kontoschlüssel ändern

    Entfernen Sie das gestohlene Gerät von einem anderen Gerät aus, oder nutzen Sie „Device compromised“: Es ersetzt Ihre Kontoschlüssel und rotiert jede Umgebung, für die Sie einen Schlüssel hatten.

    Geschützt durchKryptografieServer

  8. Jemand erlangt root-Rechte auf einer Maschine mit dem Agenten

    Eingeschränkt

    Ein Server, auf dem der Agent crunu läuft, ist ein legitimer Empfänger, und damit auch, wer ihn kontrolliert.

    Angreifer bekommen

    • Alles, was an diese Maschine ausgeliefert wird. Ein Programm, das bereits läuft, behält seine Variablen bis zum Neustart.

    Angreifer bekommen nicht

    • Andere Maschinen oder Umgebungen: Jede Maschine hat eigene Schlüssel und erhält nur, was ihr freigegeben wurde
    • Dauerhaften Zugriff: Eine Lease endet nach 24 Stunden ohne Kontakt, und eine widerrufene Maschine verwirft ihre Umgebungen innerhalb von Minuten, solange sie online ist

    Geschützt durchKryptografieServer

  9. Ein Registrierungscode gelangt nach außen

    Geschützt

    Der Einmalcode, den Sie auf einer neuen Maschine an crunu enroll übergeben.

    Angreifer bekommen

    • Die Gelegenheit, eine eigene Maschine zu registrieren, wenn der Code früher eingesetzt wird als auf Ihrer Maschine

    Angreifer bekommen nicht

    • Die Freigabe: Ein Admin gibt eine Maschine erst frei, nachdem der Fingerabdruck abgeglichen ist, den crunu enroll auf der echten Maschine ausgibt
    • Einen unbemerkten zweiten Versuch: Der Code gilt standardmäßig 15 Minuten, verfällt beim ersten Einsatz, und ein wiederverwendeter Code löst eine Warnung aus

    Geschützt durchKryptografieServer

  10. Ein CI-Token gelangt nach außen

    Eingeschränkt

    Ein Service-Token, das aus dem Secret-Speicher einer Pipeline kopiert wurde.

    Angreifer bekommen

    • Genau das, was dem Token freigegeben wurde, oft eine einzige Umgebung, bis Sie es widerrufen oder es abläuft

    Angreifer bekommen nicht

    • Irgendeine andere Umgebung: Der Schlüssel von production wird nie für ein Token versiegelt, dem production nicht freigegeben wurde
    • Eine Anmeldung von anderswo, wenn das Token per OIDC gebunden ist: Ohne das Token Ihres CI-Anbieters für das richtige Repository und den richtigen Branch kommt es nicht hinein

    Geschützt durchKryptografieServer

  11. Jemand probiert am Server Passwörter durch

    Geschützt

    Anmeldeversuche von einer Adresse oder verteilt auf viele.

    Angreifer bekommen

    • 10 Fehlversuche pro IP-Adresse und 5 pro Konto alle 15 Minuten

    Angreifer bekommen nicht

    • Einen Hinweis, dass ein Konto existiert: Eine unbekannte E-Mail-Adresse und ein falsches Passwort erhalten dieselbe Antwort
    • Zugang allein mit dem Passwort: Die Anmeldung braucht auch Ihren Secret Key, und ein neues Gerät braucht Ihren zweiten Faktor, sobald Sie einen eingerichtet haben
    • Eine Abkürzung über Codes und Links: Sie enthalten mindestens 128 zufällige Bits und werden als Hashes mit geheimem Schlüssel gespeichert

    Geschützt durchServerKryptografie

  12. Jemand manipuliert ein Release des Agenten

    Geschützt

    Eine veränderte Binärdatei crunu oder ein verändertes Installationsskript.

    Angreifer bekommen

    • Einen Weg hinein nur dann, wenn Angreifer auch die Web-App kontrollieren, die Ihren Installationsbefehl anzeigt, wie bei einer Übernahme des Servers

    Angreifer bekommen nicht

    • Eine unbemerkte Installation: Der Installationsbefehl in der Web-App enthält SHA-256-Prüfsummen aus dem Release-Manifest, und die Web-App prüft die Ed25519-Signatur des Manifests
    • Ein unbemerktes Update: crunu self-update prüft die Signatur des Releases mit einem Schlüssel, der in den Agenten eingebaut ist

    Geschützt durchKryptografieClient

  13. Schadsoftware läuft auf Ihrem Gerät

    Nicht geschützt

    Ein Keylogger, eine bösartige Browsererweiterung oder jemand mit root-Rechten auf Ihrem Computer.

    Angreifer bekommen

    • Ihr Passwort und Ihren Secret Key, während Sie sie eingeben, und alles, was dieses Gerät entschlüsselt

    Angreifer bekommen nicht

    • Umgebungen, die Ihr Konto nicht öffnen kann

    Keine Verschlüsselung kann ein Gerät vor sich selbst schützen. Nutzen Sie Geräte, die Sie kontrollieren. Verwenden Sie nach einer Kompromittierung „Device compromised“ von einem sauberen Gerät aus, und stellen Sie die Werte neu aus, die das Gerät erreichen konnte.

    Geschützt durchNichts in Crunu

Alle bekannten Grenzen und was Sie dagegen tun können

Die Kryptografie

Standardbausteine in zwei Implementierungen: das eingebaute WebCrypto des Browsers und die Standardbibliothek von Go im Agenten. Beide werden mit denselben gemeinsamen Testvektoren geprüft.

Die Kryptografie
AlgorithmusWas er in Crunu tutWo er läuft
AES-256-GCMVerschlüsselt jede Version einer Umgebung. Zusätzliche authentifizierte Daten (AAD) binden den Chiffretext an seine Organisation, Umgebung und Versionsnummer, sodass er sich nicht als ein anderer ausgeben lässt.Browser und Agent
X25519Versiegelt einen Umgebungsschlüssel für einen Empfänger: eine Person, eine Maschine oder ein Service-Token. Jede versiegelte Kopie nutzt ein neues Schlüsselpaar.Browser und Agent
Ed25519Signiert Zugriffslisten, Versionen, Freigabelinks und Releases. Geräte prüfen jede Signatur, bevor sie einem Datensatz vertrauen.Browser und Agent; Releases signiert Crunu
HKDF-SHA256Leitet aus einem Geheimnis für jede Aufgabe einen eigenen Schlüssel ab, sodass kein Schlüssel zwei Zwecken dient.Browser, Agent und Server
PBKDF2-SHA256 mit 1.000.000 Iterationen und der Secret KeyMacht aus Ihrem Passwort die eine Hälfte Ihres Kontoschlüssels. Ihr Secret Key, etwa 128 zufällige Bits, ist die andere Hälfte. Keines von beiden verlässt Ihr Gerät.Ihr Browser oder crunu im Terminal
SHA-256Verknüpft die Einträge des Audit-Logs zu einer Hash-Kette und erzeugt Fingerabdrücke von Schlüsseln, die Sie mit bloßem Auge abgleichen können.Der Server schreibt die Kette; Ihr Browser und Ihre eigenen Werkzeuge können sie nachrechnen
Auffüllen auf 4.096 ByteRundet jede verschlüsselte Version auf ganze Blöcke von 4 KB auf, damit ihre genaue Größe nicht sichtbar ist.Browser und Agent, vor dem Verschlüsseln
  • Ein Schlüssel für jede Umgebung. Zugriff auf development öffnet nichts in production. Jede Person, jede Maschine und jedes Token erhält eine eigene versiegelte Kopie nur der Schlüssel, die jeweils erlaubt sind.
  • Jedes Format trägt seine Version. Jeder Datensatz nennt seine Formatversion ("v": 2), und die Schlüsselableitung hat eine eigene (kdf.v). Geräte lehnen Versionen ab, die sie nicht kennen. So kann der Server weder das Erraten Ihres Passworts billiger machen noch ein älteres Format unterschieben.

Quantencomputer

Ein ausreichend großer Quantencomputer würde manche dieser Bausteine brechen und anderen kaum etwas anhaben. Einen solchen Computer gibt es heute nicht. Hier ist der Stand von Crunu, ohne Spekulation darüber, wann es einen geben könnte.

Quantencomputer
AlgorithmusQuantenangriffWas er für Crunu bedeuten würde
AES-256-GCMGrover-Algorithmus: eine schnellere Suche nach dem SchlüsselEs bleiben etwa 128 Bit Sicherheit. NIST geht davon aus, dass AES-256 sehr lange sicher bleibt.
SHA-256 und HMACGrover-artige SucheFür die Hash-Kette des Audit-Logs und für Hashes mit geheimem Schlüssel bleibt ein großer Spielraum. NIST nutzt SHA-256 als Maßstab für seine Post-Quanten-Sicherheitsstufen.
PBKDF2 und der Secret KeyGrover-artige Suche; der Shor-Algorithmus greift hier nichtRaten braucht weiterhin die 128 zufälligen Bits des Secret Key, so viel wie ein AES-128-Schlüssel, von dem NIST erwartet, dass er noch Jahrzehnte sicher bleibt. Weder Passwort noch Secret Key erreichen den Server.
X25519Shor-Algorithmus: der private Schlüssel aus dem öffentlichenGebrochen. Damit versiegelte Umgebungsschlüssel ließen sich öffnen.
Ed25519Shor-AlgorithmusGebrochen. Signaturen ließen sich fälschen, aber nur zum Zeitpunkt eines Angriffs. Frühere Daten werden dadurch nicht offengelegt.

Jetzt sammeln, später entschlüsseln

Jeder Umgebungsschlüssel ist für die öffentlichen X25519-Schlüssel seiner Empfänger versiegelt, und die versiegelten Kopien liegen auf dem Server neben diesen öffentlichen Schlüsseln. Wer eine Kopie der Datenbank aufbewahrt, könnte diese Kopien öffnen, sobald es einen großen Quantencomputer gibt, und die Versionen lesen, die in dieser Kopie gespeichert sind. NIST nennt diese Bedrohung „harvest now, decrypt later“.

Sie reicht nur so weit wie diese Kopie. Versionen, die nach dem Kopieren gespeichert wurden, sind nicht darin, und Zugangsdaten, die Sie beim Anbieter neu ausgestellt haben, sind wertlos für alle, die die alten entschlüsseln.

Ihr Passwort, Ihr Secret Key und Ihr Kontoschlüssel werden auf diesem Weg nicht offengelegt: Sie erreichen den Server nie, und auf sie werden nur symmetrische Verfahren angewendet. Der Angriff braucht sie auch nicht, weil er direkt auf die X25519-Schlüssel zielt.

Signaturen

Ed25519-Signaturen schützen Zugriffslisten, Versionen und Releases. Mit einem Quantencomputer ließen sich neue fälschen, doch eine Fälschung zählt erst, wenn sie erstellt und akzeptiert wird. Sie ist also ein Risiko für den Tag, an dem es einen solchen Computer gibt, nicht für Daten, die heute aufgezeichnet werden. NIST sagt dasselbe: Für Signaturen ist „harvest now, decrypt later“ keine Gefahr.

Was Crunu heute nutzt und was als Nächstes kommt

Crunu nutzt heute keine Post-Quanten-Algorithmen. NIST hat seine ersten Post-Quanten-Standards im August 2024 veröffentlicht: ML-KEM zum Vereinbaren von Schlüsseln (FIPS 203) und ML-DSA für Signaturen (FIPS 204). Sein Übergangsplan, im Oktober 2026 fertiggestellt, zählt die Schlüsselvereinbarung auf elliptischen Kurven und EdDSA zu den Algorithmen, die NIST nach 2030 als veraltet einstufen und nach 2035 in seinen Standards nicht mehr zulassen wird.

Der Umstieg auf Post-Quanten-Kryptografie steht auf der Roadmap von Crunu. Algorithmen oder Termine, die wir noch nicht zusagen können, kündigen wir nicht an: Wenn sich die Kryptografie von Crunu ändert, steht das auf dieser Seite.

Was Sie jetzt tun können

  • Überlegen Sie, wie lange jedes Secret wertvoll bleibt. Bei einem Schlüssel, den Sie alle paar Monate neu ausstellen, richtet eine Jahre später entschlüsselte Kopie wenig Schaden an, bei langlebigen Root-Zugangsdaten mehr.
  • Stellen Sie langlebige Werte nach festem Plan beim jeweiligen Anbieter neu aus und speichern Sie jeden neuen Wert als neue Version.
  • Wenn Ihnen eine Datenbankkopie in fremden Händen Sorgen macht, betreiben Sie einen eigenen Server. Die Datenbank und ihre Backups bleiben dann bei Ihnen.

Quellen

  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)

Geprüft am 28. Oktober 2026.

Selbst nachprüfen

Abzeichen oder Zertifikate haben wir noch keine vorzuweisen. Hier steht, was Sie heute prüfen können und was fehlt.

  • Signierte Releases.Jedes Release des Agenten und der Web-App ist mit einem Ed25519-Release-Schlüssel signiert. crunu self-update prüft die Signatur mit einem Schlüssel, der in den Agenten eingebaut ist, und die Web-App zeigt „Signed build“ an, sobald sie sich gegen das signierte Manifest geprüft hat.
  • Ein reproduzierbarer Web-Build.Ein Quell-Commit erzeugt immer dieselben Dateien, Byte für Byte. Der Quellcode ist nicht veröffentlicht, deshalb kann heute nur Crunu ein Release neu bauen und vergleichen.
  • Keine Skripte von Dritten.Die Content-Security-Policy (CSP) der Seite erlaubt nur den eigenen Code von Crunu, den sie mit Integritätsprüfsummen (SRI) lädt.
  • Wenige Abhängigkeiten.Der Agent nutzt nur die Standardbibliothek von Go, und der Browser-Code enthält ein einziges npm-Paket, yaml.
  • Ein Audit-Log, das Sie außerhalb von Crunu prüfen können.Owner und Admins können das Log als JSONL exportieren und seine SHA-256-Hash-Kette mit eigenen Werkzeugen nachrechnen.
  • Was fehlt.Kein externes Sicherheitsaudit, keine Zertifizierung nach SOC 2 oder ISO 27001 und kein veröffentlichter Quellcode. Crunu ist im Early Access; Audits und Nachweise nennt die Dokumente, die wir haben.
  • Ein Problem gefunden?Schreiben Sie an security@crunu.com. Denselben Kontakt finden Sie in unserer security.txt, und Bekannte Grenzen führt jede Grenze auf, die wir schon kennen.
Beispiel. Kiteline ist ein fiktives Unternehmen.

Fragen zur Sicherheit von Crunu

Kann Crunu meine Secrets lesen?

Nein. Der Server, ob von Crunu auf app.crunu.com oder von Ihnen selbst betrieben, speichert nur Chiffretext und hat keinen Schlüssel, der ihn entschlüsseln könnte. Er sieht allerdings Metadaten: Namen, E-Mail-Adressen, das Audit-Log und wann jede Version gespeichert wurde. Um an Ihre Werte zu gelangen, müsste man den Code auf Ihrem Gerät ändern, etwa über eine manipulierte Webseite. Das ist das größte verbleibende Risiko auf dieser Seite.

Was passiert, wenn der Server von Crunu gehackt wird?

Wer einbricht, bekommt Chiffretext, öffentliche Schlüssel, Hashes von Tokens mit geheimem Schlüssel und Metadaten. Damit lassen sich Ihre Werte nicht entschlüsseln, und ohne dass Ihre Geräte es bemerken, kann sich niemand in eine Zugriffsliste eintragen oder eine Version ändern. Möglich bleibt, Ihnen den Dienst zu verweigern oder eine manipulierte Webseite zu senden. Wird app.crunu.com kompromittiert, informieren wir die Personen, deren Konten betroffen sind, unverzüglich per E-Mail.

Was ist, wenn ich mein Passwort vergesse?

Niemand kann es zurücksetzen, auch wir nicht, denn wir erhalten weder Ihr Passwort noch Ihren Secret Key. Ihr ausgedrucktes Emergency Kit und ein Wiederherstellungscode sind die Wege zurück ins Konto. Verlieren Sie alles davon, lässt sich Ihr Konto nicht mehr öffnen. Owner und Admins können die geteilten Umgebungen der Organisation aber weiterhin öffnen.

Schützt Crunu vor Quantencomputern?

Teilweise. Von AES-256 und SHA-256 wird erwartet, dass sie standhalten. X25519 und Ed25519 würden einem großen Quantencomputer nicht standhalten, und einen solchen gibt es heute nicht. Crunu nutzt heute keine Post-Quanten-Algorithmen, eine über Jahre aufbewahrte Datenbankkopie könnte also eines Tages die Versionen darin offenlegen. Der Umstieg auf Post-Quanten-Kryptografie steht auf der Roadmap von Crunu.

Gibt es ein Audit von Crunu?

Nein. Crunu ist im Early Access, hat keine Zertifizierung nach SOC 2 oder ISO 27001, und es wurde kein externes Sicherheitsaudit veröffentlicht. Auch der Quellcode ist nicht veröffentlicht. Was Sie heute prüfen können, steht oben unter „Selbst nachprüfen“.

Ist ein eigener Server sicherer als app.crunu.com?

Er ändert, wem Sie vertrauen, nicht die Verschlüsselung. Ein eigener Server hält die Datenbank und ihre Backups bei Ihnen und liefert die Webseite von Infrastruktur aus, die Sie kontrollieren. Dafür werden Backups, Updates und das eigene Geheimnis des Servers zu Ihrer Aufgabe. Den Server gibt es auf Anfrage unter support@crunu.com.

Wie melde ich eine Schwachstelle?

Schreiben Sie an security@crunu.com, beschreiben Sie die Schritte, mit denen sich das Problem nachstellen lässt, und lassen Sie echte Secrets aus der Meldung heraus. Denselben Kontakt finden Sie in unserer Datei security.txt, und die Seite „Sicherheitsmodell“ nennt die Regeln für Tests.

Speichern Sie die Secrets Ihres Teams auf einem Server, der sie nicht lesen kann

Erstellen Sie Ihr Konto auf app.crunu.com. Ihre Schlüssel entstehen in Ihrem Browser, und der Server erhält nur Chiffretext.

Kostenlos im Early Access. Zum Sicherheitsmodell