1. Crittografia lato client
I messaggi vengono cifrati nel browser usando Web Crypto (AES-GCM). Il server memorizza testo cifrato e metadati.
Modello di sicurezza di EncSend
Questa pagina descrive l'implementazione attuale: quali dati sono cifrati lato client, come vengono gestiti link e chiavi, quali controlli di accesso sono attivi e dove si trovano i limiti del modello.
2. Chiavi nei frammenti URL
Le chiavi di decrittazione vengono trasportate in frammenti URL come #k o #rk e non vengono inviati al server.
3. Livello password opzionale
I link protetti da password usano hash delle password lato server più un ulteriore wrapping delle chiavi lato client (PBKDF2-SHA-256).
4. Controlli di durata
Scadenza, limiti di visualizzazione/invio e politiche di lettura singola limitano l'accesso ai contenuti sensibili.
Flusso dati: invio segreto
- 1. Il browser genera materiale di chiave del link a 256 bit.
- 2. Il messaggio viene cifrato con una chiave payload casuale tramite AES-GCM.
- 3. La chiave payload viene incapsulata con una chiave HKDF-SHA-256 derivata dalla chiave del link.
- 4. Facoltativamente, questa chiave incapsulata viene ulteriormente cifrata con un livello basato su password (PBKDF2-SHA-256).
- 5. Il server memorizza solo
encrypted_payload,encrypted_key, metadati crittografici e campi della policy di accesso. - 6. Dopo una corretta decrittazione locale, il client conferma una visualizzazione; con lettura singola, il segreto viene poi contrassegnato come distrutto.
Flusso dati: richiesta di messaggio sicuro
- 1. Il proprietario genera un URL di richiesta con un token pubblico casuale.
- 2. I mittenti esterni cifrano localmente nel browser con il materiale della chiave della richiesta dal frammento URL.
- 3. Il server memorizza gli invii come testo cifrato e applica limiti di invio e scadenza.
- 4. Il proprietario legge gli invii tramite decrittazione locale; il testo in chiaro non viene elaborato lato server.
- 5. Per la lettura multi-dispositivo, la chiave della richiesta può inoltre essere memorizzata come artefatto cifrato dal proprietario.
Controllo degli accessi e resistenza agli abusi
I token di accesso pubblico vengono generati casualmente, memorizzati solo come hash SHA-256 nel database e convalidati tramite
hash_equals.
Le password dei link non vengono mai memorizzate in chiaro e vengono verificate rispetto agli hash lato server. Le sessioni con password per i link pubblici hanno una durata limitata (120 minuti per impostazione predefinita).
Il rate limiting è attivo per endpoint critici, inclusi controlli password, invii pubblici, login e flussi di verifica.
Le operazioni lato proprietario sono protette da autenticazione, stato email verificato e politiche di autorizzazione; le modifiche sensibili di recupero richiedono una recente conferma della password.
Recupero del proprietario e vault delle chiavi
EncSend fornisce artefatti di recupero crittografati opzionali per scenari multi-dispositivo:
- Profilo crittografico del proprietario: chiave master cifrata (AES-GCM), basata su passphrase (PBKDF2-SHA-256).
- Vault chiavi utente: backup cifrato delle chiavi segrete/richiesta memorizzate localmente.
- Chiavi di richiesta cifrate dal proprietario per richiesta, inclusi batch di rotazione riprendibili con supporto ai tentativi ripetuti.
Audit e tracciabilità
Le azioni rilevanti per la sicurezza vengono registrate (ad esempio emissione di link, accesso negato, passaggi di verifica password, creazione di invii e aggiornamenti di recupero).
- Le tabelle degli eventi di accesso memorizzano il tipo di evento, il timestamp, lo user agent e i metadati contestuali.
- Log di audit per eventi importanti.
- Una migrazione dedicata rimuove le colonne degli indirizzi IP dalle tabelle relative a sessioni ed eventi.
Limiti importanti del modello
- La sicurezza del browser resta critica: le chiavi locali vengono memorizzate nella cache del browser e richiedono un ambiente client protetto.
- JavaScript e Web Crypto sono obbligatori per flussi sicuri di creazione e decrittazione locale.
- La sicurezza del trasporto (HTTPS, hardening del reverse proxy, policy TLS) deve essere applicata a livello infrastrutturale.
- L'hashing delle password protegge l'archiviazione lato server, ma non sostituisce la scelta di password robuste.