Sicurezza / Panoramica
KalderaShield è un gestore di password local-first: il tuo gestore risiede sul tuo dispositivo, la cifratura avviene lì e non serve alcun account né alcuna copia sul cloud. Questa sezione spiega esattamente come funziona quella protezione — e dove finisce.
Non esiste un account KalderaShield né una copia del gestore lato server. Il tuo gestore cifrato è conservato sul tuo dispositivo e, se lo scegli, in file di backup cifrati che sposti tu. Un attaccante non può violare un server che non esiste.
Ogni record è cifrato separatamente. Una chiave AES-256-GCM univoca a 256 bit viene derivata per ogni record tramite HKDF-SHA256, quindi decifrare un elemento non espone mai gli altri. Titoli, nomi utente, password e note esistono in chiaro solo dentro il payload cifrato autenticato.
La password principale viene espansa con Argon2id — 64 MiB di memoria, 4 iterazioni e 2 vie su desktop e Android — e i parametri sono memorizzati nel gestore, così un gestore esistente non diventa mai più debole in silenzio.
Le build di produzione girano dietro una policy di air gap: le chiamate in uscita inattese tramite fetch, WebSocket, WebRTC e simili sono bloccate e registrate. L’unico traffico di rete è il controllo per intervalli di Have I Been Pwned, che invia i primi cinque caratteri di un hash SHA-1 e mai la tua password.
Argon2id la trasforma nella chiave del gestore. La password principale non viene mai memorizzata nel sessionStorage del browser; dopo lo sblocco, lo stato della sessione è un buffer di byte in memoria che viene azzerato, non una stringa leggibile dalla pagina.
Windows Hello (TPM 2.0), Touch ID di macOS (Secure Enclave), BiometricPrompt di Android (AndroidKeyStore) e le chiavi FIDO2 con supporto PRF avvolgono il payload di sblocco. Il file del gestore non è mai sigillato dall’hardware, quindi un dispositivo perso non ti preclude mai l’accesso.
Il modello delle minacce pubblicato dichiara quali attacchi sono difesi, quali solo parzialmente e quali sono fuori dal perimetro — incluso il malware in esecuzione nella tua sessione del sistema operativo. Le affermazioni del prodotto non possono promettere di più.
Nessuna applicazione locale può proteggere un gestore su un dispositivo compromesso: il malware in esecuzione con il tuo account del sistema operativo mentre il gestore è sbloccato, i keylogger, l’acquisizione privilegiata dello schermo e l’ispezione della memoria sono tutti fuori da questo modello. Lo sblocco hardware è un involucro di comodità, non un sostituto della password principale. Un audit indipendente di terzi non è ancora stato completato — lo si dichiara apertamente, non lo si nasconde.
64 MiB, 4 iterazioni, 2 vie per i nuovi gestori su desktop e Android; 32 MiB, 3 iterazioni, 1 via per le build web.
HKDF-SHA256 deriva una chiave univoca per ogni record e per ogni allegato, usando l’id del record come salt. Un ciphertext manomesso non supera la verifica di autenticazione.
Le destinazioni in uscita inattese tramite fetch, XHR, WebSocket, sendBeacon, EventSource e WebRTC sono bloccate e registrate come eventi di sicurezza.
No. Non esiste un account né un gestore lato server. I provider di sincronizzazione facoltativi come WebDAV e S3 caricano solo il payload cifrato su un archivio che configuri e possiedi tu.
No, e nessun altro può farlo. Sblocca con la password principale, con la chiave di ripristino BIP-39 a 24 parole, oppure ripristina un backup cifrato. Senza una di queste possibilità il gestore non può essere aperto.
Non ancora. La pagina sullo stato dell’audit lo dichiara apertamente e descrive la verifica automatizzata presente oggi. Nascondere un audit non completato contraddirebbe tutto il resto di questo sito.
Kaldera