Schema di password Hash (master + nomehost) per un pool di server

Alcune idee:

• Utilizza uno schema che ti consente di "sfiorare" facilmente le password in un valore successivo per quando è necessario modificare le password. Se hai mai bisogno di dare a qualcuno la tua password del server (cosa che accade in alcuni tipi di emergenza), allora ti consigliamo di cambiare la password per revocare l'accesso. Non bloccarti nel mantenere una password che non puoi cambiare facilmente.

• Non utilizzare password per le interazioni quotidiane con il server. Le chiavi SSH sono categoricamente migliori, specialmente quando hai molti server da gestire. Scopri come utilizzare un agente chiave ssh ( ssh-add su * nix e pageant su windows), che ti aiuta a semplificare la gestione delle chiavi e non ti dà scuse per non crittografare la tua chiave privata.

• Inoltre, LastPass. Non proprio rilevante per le password ssh e root, ma se gestisci molti server, probabilmente inserirai molte password nei browser. Questo è sicuro e riduce il tuo incentivo a riutilizzare le password.

Come nota di implementazione, volevo solo sottolineare che il tuo input hash ha un \n implicito alla fine che viene inserito da echo . Quindi, se mai tentassi di replicare la password in Perl o usando qualche altro strumento, tienilo a mente. In alternativa: echo -n 'foo' 'bar' | md5sum . Vedi anche: echo $(</root/secret.txt) "hostname" | md5sum

• Il nome host del server non è un segreto
• MD5 è essenzialmente compromesso (https://en.wikipedia.org/wiki/MD5#Security). Non sono sicuro che le particolari debolezze di MD5 siano sfruttabili in questo scenario, in quanto si tratta principalmente di vulnerabilità di collisione.

Il problema che stai cercando di risolvere, ricordando più di 20 password di root, può essere risolto in modo più sicuro utilizzando una delle seguenti routine:

• Usa l'autenticazione della chiave ssh invece delle password (ma assicurati di avere una buona passphrase per le tue chiavi); questo non è solo più sicuro, ma puoi anche revocare l'accesso per qualsiasi tasto in qualsiasi momento semplicemente cancellando il tasto pub dal server. Questo è di gran lunga il metodo migliore che riesco a pensare.
• Genera password casuali (cat alcuni byte da / dev / random, massaggi in materiale password) e memorizzali in un file crittografato che porti con te. La crittografia GPG con una buona chiave e passphrase dovrebbe fare il trucco; poiché GPG è impostato per decodificare su stdout, il rischio di lasciare accidentalmente le password in un file non crittografato o nella cronologia è ridotto; rimarrà ovviamente nel buffer di linea del tuo terminale. Ovviamente, questo significa che devi avere a portata di mano la tua chiave privata ogni volta che devi decodificare quel file.
• Utilizza una soluzione di password singola di terze parti come LastPass. Questa è solo un'opzione se ti fidi della soluzione di terze parti però.

Questo rischio principale che vedo è questo. I 'serverhostnames' sono (molto probabilmente) informazioni non segrete, quindi se la password principale è compromessa, allora lo sono tutte.

EDIT : Inoltre, sembra che la tua 'password principale' non sia casuale. Non menzioni se hai delle regole per sceglierlo (come lunghezza, tipi di caratteri, ecc.)

Se usi le password, dovresti renderle ad alta entropia e resistenti agli attacchi di dizionario e di indovinamento della password. La cosa migliore sarebbe generare una password casuale di lunghezza massima sul set completo di caratteri e seguire le linee guida NIST sulla creazione di un password ad alta entropia.

Il primo "problema luminoso" che vedo qui è che questo schema non utilizza l'intero set di caratteri ASCII. L'entropia non è buona come potrebbe essere (vedi la sicurezza della password ).

Questo porta direttamente al secondo problema. passwordmeter mi dice che la chiave hash per "1234" ( e7df7cd2ca07f4f1ab415d457a6e1c13 ) ha la stessa forza di "So Long, e grazie For All the Fish "( 8121c5d059fd0a23dc7a436c56085188 ). Quindi la tua password principale può essere semplice, come una data di nascita o un codice PIN di chipcard, o complessa, senza guadagnare più entropia.

EDIT:

Capisco i critici e i downvotes. Spiacente, il mio post non è stato completato. L'equivoco è che non intendevo usare la chiave hash direttamente come password, ma come la password per i volumi TrueCrypt o GnuPG. Poiché TrueCrypt utilizza PBKDF-2 per archiviare le chiavi internamente, ad esempio, dovrebbe essere impossibile per un utente malintenzionato trovare questa chiave. Si noti inoltre che è impossibile precalcolare e memorizzare tutte le somme MD5, anche se non le prime 2 ^ 64. E MD5 è solo un esempio; in pratica preferiresti usare SHA-1 o SHA-256.

D'altra parte tu (e solo tu) puoi facilmente riprodurre la chiave. Puoi anche dare la semplice password ad un amico - finché nessuno conosce l'algoritmo / sale che applichi su di esso la password dovrebbe essere inutile. Una semplice password che è già elencata su Internet potrebbe anche proteggerti allora.