Sicurezza
Dimostrazione che il Suo browser non è una cassaforte.
Chrome e Firefox salveranno le Sue password — e poi le forniranno a qualsiasi programma in esecuzione come Lei. Non è un bug. È il design. Ecco la dimostrazione: una volta in linguaggio chiaro, una volta in codice.
La versione in linguaggio chiaro
Il "gestore password" del Suo browser è protetto da un unico lucchetto: l'accesso al Suo computer. Una volta effettuato l'accesso al Suo laptop, il browser può leggere istantaneamente ogni password salvata — quindi anche qualsiasi altra cosa in esecuzione sul Suo account può farlo.
Un download errato. Un gioco per browser sospetto. Un pacchetto avvelenato in un progetto che ha clonato. Nel momento in cui viene eseguito — mentre Lei è connesso, come sempre — legge ogni password salvata dal Suo browser, nel tempo necessario per aprire un file. Non c'è una password principale da decifrare, perché non c'è nulla da decifrare: il browser è stato creato per sbloccare automaticamente per Lei, e il malware chiede semplicemente gentilmente come "Lei".
Questo non è teorico. È il modo più comune in cui le persone comuni perdono i loro account. Il malware ha persino un nome noioso nel settore — "info-stealer" — perché è così di routine. Le Sue password, le Sue carte salvate, i Suoi cookie di sessione: copiati e persi prima che Lei se ne accorga.
La soluzione è semplice da affermare: le Sue password dovrebbero essere bloccate con qualcosa che il resto del Suo computer non possiede — e non dovrebbero risiedere affatto sulla macchina.
La versione con prove
Non si fidi solo della nostra parola. Chromium e Firefox sono open source, e il percorso di lettura è documentato, standard e breve. Ecco esattamente dove si trovano le password e come vengono estratte.
Chrome (e ogni browser Chromium)
Chrome memorizza i login in un database SQLite — Login Data, tabella logins, colonna password_value — crittografato con AES-256-GCM. La chiave AES si trova in Local State, "protetta" dal sistema operativo: DPAPI su Windows, il Keychain di accesso su macOS, gnome-keyring/kwallet (o testo in chiaro) su Linux.
Lo legga Lei stesso — il codice è aperto. Cerchi in Chromium la costante che contrassegna la chiave avvolta: kDPAPIKeyPrefix in os_crypt. La chiave è avvolta da DPAPI, contrassegnata e memorizzata — quindi spacchettata con una singola chiamata che non protegge nulla da Lei:
const char kDPAPIKeyPrefix[] = "DPAPI";
CryptUnprotectData(&intermediate, /*ppszDataDescr=*/nullptr,
/*pOptionalEntropy=*/nullptr, nullptr, nullptr, 0, &output);Nessun secondo segreto, nessuna password, nessun prompt. CryptUnprotectData restituisce la chiave a qualsiasi processo in esecuzione nella Sua sessione — che è esattamente il modello di minaccia documentato da DPAPI: se viene eseguito come Lei, è Lei. L'intero lavoro dell'attaccante consiste in tre righe: leggere la chiave da Local State, spacchettarla, decrittografare AES-GCM ogni riga in Login Data. Il malware info-stealer fa esattamente questo da anni.
Anche la "crittografia sul dispositivo" non La salva
La risposta di Google è un PIN di 6 cifre che crittografa la Sua cassaforte sincronizzata. A maggio 2026, ricercatori di Phishu hanno dimostrato quanto sia debole. Un finto accesso Google convincente — phishing "adversary-in-the-middle" — cattura la sessione e quel PIN, e il PIN è la chiave principale per ogni password e passkey nell'account sincronizzato. Con esso, un attaccante aggiunge il proprio dispositivo al Suo "dominio di sicurezza" Google e l'intera cassaforte viene sincronizzata direttamente a loro — un completo dirottamento in un unico passaggio.
Il difetto di progettazione: Google consente a un dispositivo di unirsi solo con il PIN di 6 cifre, senza approvazione da un dispositivo già in Suo possesso.
Firefox
Firefox conserva i login in logins.json e la chiave in key4.db, decrittografata dall'"Anello Decrittatore Segreto" di NSS — anch'esso open source: security/nss/lib/pk11wrap/pk11sdr.c. Se imposta una Password Primaria, la chiave viene sigillata con essa.
Per impostazione predefinita, non l'ha fatto — quindi la chiave è sigillata con la stringa vuota, e un valore "password-check" memorizzato conferma che la password vuota la decrittografa. Copi due file dal Suo profilo (key4.db + logins.json), li punti a NSS o all'open source firepwd.py, e questi li decrittografano. Un lucchetto la cui chiave è attaccata alla porta non è un lucchetto.
Ogni archivio password del browser ha la stessa struttura: il segreto risiede dove Lei lavora, sbloccato dalla sessione in cui è già attivo. La crittografia che il resto del Suo computer può annullare non La protegge dalla minaccia che svuota effettivamente gli account — codice in esecuzione come Lei.
Perché Clavitor non può essere letto in questo modo
Clavitor non conserva la Sua cassaforte sulla macchina. Non c'è Login Data, nessun key4.db, nessuna chiave in Local State — nulla sul disco che un processo in esecuzione come Lei possa estrarre.
La chiave di decrittografia non è sigillata con l'accesso al Suo sistema operativo. Viene derivata da un tocco hardware — Touch ID, Face, o una YubiKey — calcolata nel browser, utilizzata per una singola richiesta, quindi scartata. Una credenziale viene recuperata tramite un'API con ambito limitato esattamente quando Lei la richiede, e mai memorizzata nella cache. Il malware in esecuzione come Lei trova un armadio vuoto.
Questa è la differenza tra "crittografato sul Suo dispositivo" e "non sul Suo dispositivo affatto".
Smetta di fidarsi del browser per le Sue password.
L'estensione Clavitor compila come il Suo browser — e mantiene la cassaforte in un luogo che il Suo laptop non può leggere.