Maximalista zero-knowledge · privát béta

A titkainak nevei
szintén titkosítva vannak.

A legtöbb B2B titokkezelő szigorúan titkosítja a jelszavak tartalmát, mégis tiszta szövegben hagyja a szerverén a neveket, a típusokat és a társított URL-eket. Ha az adatbázis kiszivárog, a támadó elolvassa a tevékenysége teljes térképét anélkül, hogy egyetlen értéket is vissza kellene fejtenie. A(z) ARDNTECH a zero-knowledge-t minden metaadatra alkalmazza: a nevek, a kindek, az URI-k a böngészőből titkosítva vannak az OpenPGP SEIPDv2 segítségével. A szerver csak egy átláthatatlan blobot tárol.

Csatlakozás a privát bétához A fenyegetési modell elolvasása

OpenPGP SEIPDv2 ChaCha20-Poly1305 / AES-256 Titkosított nevek Titkosított típusok Titkosított URL-ek Automatizált rotáció

01 / A probléma

Amit a legtöbb széf tiszta szövegben hagy.

Amikor egy "zero-knowledge" kezelőről beszélünk, azonnal a jelszó értékére gondolunk. Mégis, ezen érték körül legalább annyira beszédes metaadatok keringenek: a titok neve, a típus, az érintett domain, a mappafa. Sok termék kizárólag az értéket titkosítja, és a többit kiteszi a szerverének, ergonómiai okokból. A költséget ritkán teszik egyértelművé.

Amit egy adatbázis-dump felfedhet anélkül, hogy egyetlen értéket is visszafejtene

Képzelje el, hogy egy támadó hozzáfér egy olyan kiadó adatbázisának teljes másolatához, amelynél csak a jelszótartalom van titkosítva. Anélkül, hogy egyáltalán megtámadná a kriptográfiát, rekonstruálhatja a belső térképét:

egy "Production AWS · gyökér · root account" nevű titok egy "DevOps / Cloud" mappában, egy CTO-fiók tulajdonában;
egy "SAP HANA · prod EMEA" nevű titok, megosztva négy pénzügyi fiókkal;
egy "BNP bankszámla · SCI X" nevű titok, megosztva két vezető között;
egy "Vagyonfelügyelő · Y dosszié" nevű titok egy ügyvédi irodában;
tiszta szövegű URL-ek, amelyek a belső eszközökre mutatnak: jira.entreprise.com, vpn.entreprise.com, kibana.entreprise.com.

A támadó egyetlen jelszót sem fejtett vissza. Mégis máris ismeri a stackjét, a partnereit, az érzékeny dossziéit, és mindene megvan ahhoz, hogy egy nagyon meggyőző phishing-támadást célozzon a megfelelő emberekre. Pontosan ezt nevezik "haszontalan zero-knowledge" szivárgásnak.

A név mindent elmond

A név az első információs sor: megjelöli az alkalmazást, a fiókot, néha a környezetet. Egy gondos belső elnevezési konvenció annál inkább kiteszi. Titkosítás nélkül a szervezete indexévé válik.

A típus kategorizálja a kockázatot

Credential típus, certificate típus, API-kulcs típus, TOTP seed típus: mindegyik tájékoztat az érzékenységről és a lehetséges pivotokról. Egy támadó néhány másodperc alatt válogat, hogy elkülönítse a tanúsítványokat és az API-kulcsokat.

Az URL elárulja az ökoszisztémát

A fő és alternatív URL-ek leírják a teljes technikai stackjét és a partnerkapcsolatait. Lehetővé teszik egy támadó számára, hogy feltérképezze a kerületét egyetlen hálózati kérés nélkül az áldozat oldalán.

02 / A mi megközelítésünk

Egy kriptográfiai boríték entitásonként.

Minden titok és minden mappa két átláthatatlan oszlopot hordoz a szerver oldalán. A tiszta szövegű tartalom, amely a nevet, a típust és a sablonhivatkozásokat tartalmazza, JSON-ba van szerializálva, majd a böngésző oldalán OpenPGP segítségével SEIPDv2 módban titkosítva, ugyanazzal a kulccsal, mint amely a payload titkosítására szolgál. A szerver soha nem fejti vissza ezeket a blobokat.

Plaintext

Metaadat-mezők

A szerializált tiszta szöveg tartalmazza a sémát (metadata/v1 egy titokhoz, folder_metadata/v1 egy mappához), a nevet, a kindet (credential, api_key, certificate, note, totp vagy org_template) és az esetleges hivatkozást egy szervezeti sablonra. E mezők egyikét sem olvassa vagy kezeli a szerver.

Chiffrement

OpenPGP SEIPDv2 a böngészőben

A tiszta szöveg OpenPGP RFC 9580-ban, SEIPDv2 módban van titkosítva, az ügyfél választása szerinti AES-256-GCM vagy ChaCha20-Poly1305 szimmetrikus cipherrel. A művelet a felhasználó böngészőjében zajlik az OpenPGP.js v6 segítségével, amelyet a Cure53 auditált. Semmilyen szerveroldali származék nem lép közbe.

Stockage

Két átláthatatlan oszlop a szerver oldalán

A szerver két oszlopot tárol entitásonként: az encrypted_metadata, amely a páncélozott PGP-üzenetet tartalmazza, és a metadata_envelope, amely egy minimális JSON wrappert tartalmaz (verzió, algoritmus és a ciphertext másolata). Semmilyen köztes mező nem írja le a tartalmat tiszta szövegben.

Partage

Közvetlen újratitkosítás a címzett számára

Amikor egy titkot megosztanak, a tiszta szöveg közvetlenül a címzett nyilvános kulcsára kerül újratitkosításra. Nem létezik szállítás közben védendő köztes szimmetrikus kulcs, sem egy támadó számára látható szerveroldali "mesterkulcs". Kevesebb felület, több költség a blobok újrakibocsátásában: egy vállalt architekturális választás.

Visszafejtés a böngésző és a bővítmény oldalán

A megjelenítés pillanatában a böngésző lekéri az átláthatatlan borítékokat, visszafejti őket egy SharedWorkeren keresztül, amely elszigeteli a privát kulcsot az oldal kontextusától, és a tiszta szöveget a sessionStorage-ben gyorsítótárazza a lap időtartamára. A gyorsítótár automatikusan ürül a széf zárolásakor, a kijelentkezéskor és a lap bezárásakor. A böngészőbővítmény ugyanezt a modellt követi egy dedikált browser.storage.session gyorsítótárban.

03 / Tényszerű összehasonlítás

Titkosított metaadatok kiadónként.

Az alábbi táblázat több elismert piaci kiadó esetében leírja, ahogyan a fő metaadatok tárolva vannak a nyilvános dokumentációjuk szerint. Az említett termékek általános minőségét nem kérdőjelezzük meg: az összehasonlítás kizárólag erre a pontos körre vonatkozik. Az információk 2026-08-01 keltezésűek, és gyorsan változhatnak.

Kiadó	A titok neve	Típus / kind	URL / URI
ARDNTECH	A böngésző oldalán titkosítva (OpenPGP SEIPDv2)	A böngésző oldalán titkosítva	A böngésző oldalán titkosítva
Bitwarden	A nyilvános dokumentáció szerint: az elem neve tiszta szövegben tárolva az adatbázisban a szerveroldali keresési és autofill funkciókhoz.	Típus (login, card, identity, secure note) látható a szerver oldalán.	A társított URL-ek láthatók a szerver oldalán.
1Password	Titkosított metaadatok a nyilvános specifikációban. Pozícióparitás ezen a pontos mezőn.	Titkosítva a nyilvános specifikációban.	Titkosítva a nyilvános specifikációban.
Proton Pass	A böngésző oldalán titkosított metaadatok a nyilvános dokumentációban.	A böngésző oldalán titkosítva.	A böngésző oldalán titkosítva.
Dashlane	A nyilvános dokumentáció szerint: az item neve tiszta szövegben tárolva a szerver oldalán a cross-device kereséshez és az autofillhez.	Az item típusa látható a szerver oldalán.	A társított domainek láthatók a szerver oldalán.
NordPass	A nyilvános dokumentáció szerint: a név és a típus a szerver oldalán kitéve a szolgáltatás által asszisztált kereséshez és autofillhez.	Típus kitéve a szerver oldalán.	A társított domainek kitéve a szerver oldalán.
Passbolt v5.4 et supérieur	Titkosított metaadatok (dedikált boríték az v5.4-ben bevezetve). Pozícióparitás a(z) ARDNTECH-szel.	Titkosítva.	Titkosítva.

Források: a kiadók nyilvános termékdokumentációja és whitepaperjei, a megjelölt napon megtekintve. Egy szerver oldalon nem titkosított nevű titok jelenléte nem kriptográfiai hiba; ez egy termékválasztás, amelyet a szerveroldali keresési és asszisztált autofill funkciók motiválnak. Az ARDNTECH és a Passbolt az ellenkező választást teszi: maximális bizalmasság, kliensoldali keresés a helyi visszafejtés után. Ha egy információ pontatlannak tűnik, lépjen kapcsolatba a legal@aegirex.eu címmel, és ezt az oldalt javítjuk.

04 / Dokumentált kompromisszum

A vállalt UX-költség.

A nevek titkosításának látható költsége van az ergonómia oldalán. Inkább dokumentáljuk ezt a költséget, mintsem hogy feloldjuk a marketingígéretben. A pozíció a(z) {{ app_name }} fenyegetési modelljében van kifejtve, a vállalt kompromisszumoknak szentelt szakaszban.

Coût technique

A szerveroldali keresés már nem lehetséges

Semmilyen LIKE vagy ORDER BY SQL-lekérdezés a néven nem fogalmazható meg a szerver által: csak egy átláthatatlan blobbal rendelkezik. A néven végzett minden szűrési, rendezési vagy keresési műveletnek a visszafejtés után, tehát a kliens oldalán kell zajlania. Ez a klasszikus optimalizálásokról való kifejezett lemondás.

Mitigation

Kliensoldali szkennelés a helyi visszafejtés után

A(z) ARDNTECH kliensoldali szkennelést alkalmaz: a SharedWorker a széf betöltésekor batch-ben visszafejti a borítékokat, feltölt egy sessionStorage gyorsítótárat, és lehetővé teszi az azonnali keresést helyi szűrővel a visszafejtett tiszta szövegen. Egy 500 bejegyzéses egyéni széf esetén az érzékelt késleltetés az első betöltésnél 250 milliszekundum alatt marad, utána pedig nulla.

Limite haute

Nagyon nagy méretű széfek

Egy ugyanazon szervezeten belüli több ezer titkon túl a batch visszafejtés költsége érezhetővé válik. Az érintett szervezetek számára egy mappánkénti lusta betöltési stratégia és egy munkamenetek között perzisztens helyi index van előkészületben. Ez a korlát nem érinti a B2B felhasználások nagy többségét.

Posture

Fenyegetési modell 5.1 szakasz

A fenyegetési modell fejlett bizalmasságnak szentelt szakasza részletesen leírja ezt a kompromisszumot, beírja a STRIDE/LINDDUN mátrixba, és felsorolja az ellenintézkedéseket. A kompromisszum a kifejezett termékszerződés része. Semmilyen kereskedelmi beszéd nem kicsinyíti.

05 / Rotáció

A metaadat-kulcsok rotációja.

A metaadatok titkosításának időben csak akkor van értéke, ha egy rotációs eljárás kíséri. Egy hozzáférés-visszavonás, egy alkalmazott távozása, egy kompromittálódás gyanúja megköveteli a blobok újrakibocsátását, hogy kizárja azt a kulcsot, amelynek már nem kell visszafejtenie őket.

Visszavonás által kiváltott rotáció

Amikor egy megosztást visszavonnak, vagy egy tag elhagy egy szervezetet, automatikusan létrejön egy rotációs job. Felsorolja az összes érintett titkot és mappát. A jogosult kliensek lemerítik a jobot, újrakibocsátják a blobokat a visszavont kulcs nélkül, és megerősítik a szervernek.

Periodikus szervezeti rotáció

Egy adminisztrátor kiválthatja a szervezet teljes periodikus rotációját egy "90 naponta" vagy hasonló szabályzat betartására. A job a szolgáltatás megszakítása nélkül újrakibocsátja a metaadat-borítékok összességét.

On-demand és gyanú szerinti rotáció

Egy adott titok vagy mappa esetén egy adminisztrátor azonnali rotációt kérhet, akár megelőző módban, akár "kompromittálódás gyanúja" módban. Az indok típusos a HMAC audit láncban, ami megkülönbözteti a sürgős rotációkat a higiéniai rotációktól.

Dedikált audit lánc

Minden lépés (a job indulása, item feldolgozása, befejezés, hiba, lejárat) bekerül a HMAC-SHA-256 láncba egy dedikált kind-dal. A rotáció nyomonkövethetősége számon kérhető és ellenőrizhető ugyanazon a szinten, mint a többi kritikus esemény.

Paritás a Passbolt v5.6 rotációval

A metaadat-rotációs képesség a Passbolt 5.6-os verziójával paritásban került leszállításra, amely hasonló, megosztott szimmetrikus kulcsú modellt kínál. A(z) ARDNTECH egy megosztott szimmetrikus kulcs nélküli architektúrát választ: minden blob közvetlenül minden címzett nyilvános kulcsára van titkosítva. Ez megszünteti a "mesterkulcsot" mint támadási célpontot, cserébe egy címzettenkénti újrakibocsátási költségért. A 10 000 titoknál kisebb szervezeti vaultok esetén a felár elhanyagolható.

06 / Kinek

Négy helyzet, ahol ez nem alku tárgya.

Bizonyos szervezetek számára egy titok neve nem metaadat, hanem önmagában is érzékeny adat. Íme négy szakmai kategória, amelyek számára a nevek titkosítása nem bónuszfunkció, hanem alkalmassági feltétel.

Bank és szabályozott pénzügy

Egy "Swift HSM adminisztráció" vagy "EUR traders desk hozzáférés" nevű fiók neve egy szivárgásban elég ahhoz, hogy egy célzott támadást irányítson rendkívül érzékeny eszközök felé, anélkül hogy bármilyen jelszó felfedésre került volna. A prudenciális szabályozás e felület minimalizálására ösztönöz.

Ügyvédi irodák

A szakmai titok bizonyos ügyfélkapcsolatok és dossziék puszta létezésére is kiterjed. Egy "X vezető dosszié · büntetőeljárás" típusú titoknév, amelyet tiszta szövegben hagynak a szerver oldalán, elárulja egy eljárás létezését, amelynek felfedését az etika tiltja.

Védelmi ágazat és érzékeny önkormányzatok

A létfontosságú üzemeltetők, a biztonsági szolgálatok és bizonyos önkormányzatok természetüknél fogva olyan információkat kezelnek, amelyek puszta listája hasznos hírszerzést jelent egy ellenfél számára. A nem titkosított metaadatok összeegyeztethetetlenek az elszigetelés igényével.

Oknyomozó újságírók

Egy forrás neve, egy folyamatban lévő nyomozás címe, egy riasztásjelző rendszer URL-je: mind olyan információk, amelyek a szerver oldalán kitéve veszélybe sodorják az újságírók forrásvédelméről szóló törvény által védett forrásokat.

07 / Kezdés

Maximalista zero-knowledge,
alapértelmezetten és felár nélkül.

A metaadatok teljes titkosítása minden ARDNTECH ajánlatban benne van, az ingyenes csomagot is beleértve. Semmilyen upsell, semmilyen fizetős modul, semmilyen aktiválandó opció. Kérjen hozzáférést a privát bétához a pozíció értékeléséhez egy pilot szervezeten, vagy olvassa el a teljes fenyegetési modellt, hogy elhelyezze ezt a kompromisszumot a megoldás átfogó architektúrájában.