Questa è la parte più delicata di Server Manager dal punto di vista della sicurezza. Ecco esattamente cosa succede alle tue credenziali SSH in ogni fase.
Quando colleghi un server (senza salvarlo)
Il percorso predefinito: inserisci IP del server, nome utente e password/chiave privata nella finestra di connessione, poi fai clic su Connetti.
- Le tue credenziali vengono inviate a Server Manager tramite HTTPS
- Restano nella memoria del processo della sessione lato server che comunica con la tua VPS
- Non viene scritto nulla su disco. Nessun database, nessun file di log, nessuna cache.
- Quando ti disconnetti, chiudi la scheda del browser o la sessione scade, le credenziali vengono eliminate dalla memoria
Se il nostro server viene riavviato, le tue credenziali spariscono: la volta successiva dovrai riconnetterti manualmente. È una scelta precisa.
Quando salvi un profilo server (facoltativo)
Se selezioni "Salva questo server" durante la connessione, cifriamo le tue credenziali con una frase segreta che conosci solo tu.
Cosa viene cifrato
Il blob cifrato contiene la tua password SSH OPPURE la tua chiave privata + l'eventuale frase segreta della chiave. Include anche una piccola intestazione di metadati, così sappiamo quale tipo di credenziale usare.
Come funziona la cifratura
- Fornisci una frase segreta al momento del salvataggio (ti consigliamo di sceglierne una che non usi per nient'altro)
- La frase segreta passa attraverso scrypt — una funzione di derivazione della chiave basata su password, volutamente lenta — con un salt casuale di 16 byte diverso per ogni server, per produrre una chiave AES a 256 bit
- Le tue credenziali vengono cifrate con AES-256-GCM (cifratura autenticata: se il testo cifrato viene manomesso, la decifratura fallisce; niente attacchi padding-oracle)
- Nel database salviamo il testo cifrato, il salt, il nonce GCM e il tag di autenticazione GCM
- La tua frase segreta non viene mai salvata. Né come hash, né derivata, né in qualunque altra forma sui nostri sistemi.
Come distinguiamo "frase segreta sbagliata" da "dati manomessi"
Entrambi i casi falliscono nello stesso modo: il controllo del tag di autenticazione AES-GCM non riesce. Non esiste un verificatore salvato con cui confrontare la tua frase segreta, né un hash che possa essere esposto. Frase segreta sbagliata = errore di decifratura = la reinserisci e riprovi.
Quando ti riconnetti a un server salvato
Incolli la tua frase segreta. Noi deriviamo di nuovo la chiave con scrypt + il salt salvato, decifriamo il blob delle credenziali, usiamo le credenziali decifrate per aprire la sessione SSH e poi eliminiamo subito dalla memoria le credenziali decifrate appena la sessione è stabilita.
Le credenziali SSH decifrate esistono solo nel codice che gestisce la sessione, per la durata della connessione SSH stessa. Esattamente come nel flusso senza salvataggio descritto sopra: solo memoria, niente disco.
Cosa succede se il nostro server viene compromesso
È la minaccia contro cui abbiamo progettato questo sistema. In concreto:
- Un attaccante ottiene accesso in lettura al database: ottiene testo cifrato. Per usare una qualsiasi credenziale salvata, deve forzare la frase segreta di quel server. - scrypt è intenzionalmente lento: ogni tentativo di frase segreta richiede ~100ms+ di CPU su hardware moderno. Forzare anche una frase segreta casuale di 6 caratteri richiede anni su una singola macchina, decenni su GPU comuni.
- Un attaccante ottiene compromissione completa del server (RCE — esecuzione di codice da remoto — durante una sessione attiva): potrebbe leggere le credenziali decifrate degli utenti online in quel momento. Ma non ottiene accesso alle credenziali salvate degli utenti non connessi.
- Un attaccante ottiene un backup del database della settimana scorsa: come per l'accesso in lettura, ha solo testo cifrato.
Cosa significa per te, in pratica
I tre scenari sopra comportano esposizioni molto diverse nel mondo reale:
- Lettura del database o backup rubato (il tipo di violazione più comune): l'attaccante ottiene blob cifrati e nient'altro. Per usare davvero una qualsiasi credenziale salvata dovrebbe forzare la tua frase segreta, cosa che scrypt rende impraticabile se è robusta. I tuoi server restano al sicuro.
- Compromissione completa del server mentre sei connesso attivamente (rara e grave): poiché una sessione SSH aperta ha bisogno delle tue credenziali reali in memoria, un attaccante che controlla il nostro processo in esecuzione in quella finestra potrebbe estrarre le credenziali decifrate degli utenti connessi in quel momento e usarle per accedere ai server effettivi di quegli utenti. Se in quel momento sei offline, per lui le tue credenziali salvate sono ancora solo testo cifrato: non sei coinvolto.
La proprietà chiave: anche nello scenario da incubo di compromissione completa, il raggio d'impatto è limitato a "chiunque sia online durante l'attacco", non a "chiunque abbia mai usato Server Manager." La maggior parte delle violazioni catastrofiche espone i segreti di tutti gli utenti in una volta sola; questo design evita deliberatamente che accada.
| Tipo di violazione | Cosa ottiene l'attaccante |
|---|---|
| Lettura del database (più comune) | Solo testo cifrato — nessuna credenziale utilizzabile |
| Backup DB rubato | Solo testo cifrato |
| RCE su sessione attiva completa (rara, grave) | Credenziali decifrate dei soli utenti connessi in quella finestra |
Questa è una protezione concreta contro il modello di violazione più comune (esfiltrazione di dati), e accetta deliberatamente che un attaccante con compromissione completa del server attivo sia una minaccia diversa e più difficile, che non pretendiamo di neutralizzare del tutto — pur limitando anche quel caso peggiore agli utenti online in quel momento.
Consigli per una frase segreta robusta
L'intero schema di cifratura è forte solo quanto la tua frase segreta. Consigliamo:
- Almeno 20 caratteri casuali, oppure
- Cinque parole italiane casuali (sullo stile di "correct horse battery staple") — facili da ricordare, difficili da forzare
- Non riutilizzare mai la frase segreta che usi per accedere al laptop, al gestore di password o alla email
- Non condividerla. Server Manager non ne ha bisogno: riguarda solo te e il blob cifrato.
Se perdi la frase segreta, le credenziali salvate non possono essere recuperate. Dovrai eliminare il profilo server salvato e aggiungerlo di nuovo da zero.
Perché non offriamo accesso con chiave "senza password" o "per comodità"
Alcuni prodotti salvano le chiavi SSH senza cifratura ("fidati, le teniamo al sicuro") oppure le proteggono solo con la password dell'account utente. Server Manager no. Il meccanismo della frase segreta è ciò che separa "chiunque abbia il nostro database può entrare via SSH nei tuoi server" da "chiunque abbia il nostro database deve prima forzare la tua frase segreta." Secondo noi vale il piccolo fastidio iniziale di scegliere una frase segreta.
Cosa non viene MAI inviato o salvato
- Chiavi private SSH in chiaro nel nostro database
- Password SSH in chiaro nel nostro database
- La tua frase segreta di cifratura — da nessuna parte, in nessuna forma
- Credenziali decifrate in qualunque archiviazione persistente — disco, log, backup, cache
L'unico posto in cui esistono credenziali decifrate è la memoria del processo della sessione attiva, e solo per la durata della sessione.
Domande o dubbi?
Se qualcosa in questo articolo non è chiaro, o se hai una domanda specifica sulla sicurezza relativa al modo in cui vengono gestite le tue credenziali, scrivici tramite Contatto: saremo felici di spiegarti tutto più nel dettaglio.