Vale la pena di archiviare le password FTP crittografate?

Mi chino verso "naah, non preoccuparti", anche se non penso che ci sia una sola risposta chiara. In linea di principio, dipende da quali dati e risorse a cui tali password concedono l'accesso, oltre a quanto sia strettamente protetto la macchina su cui verranno archiviati.

Se le password saranno archiviate su una macchina che è ragionevolmente ben protetta, e se i dati a cui concedono l'accesso non sono super-critici, allora non mi preoccuperei di crittografarli. D'altra parte, se le password consentono l'accesso a dati altamente sensibili, allora sì, vorrei crittografare le password e forse prendere in considerazione anche protezioni aggiuntive - ma allora, in quel caso, forse non dovresti archiviarlo su terzi -party server FTP protetti da password in chiaro. Nella maggior parte dei casi, non mi preoccuperei di crittografare la password.

Suggerimento: se sei preoccupato, considera se sarebbe facile cambiare le password regolarmente tramite un processo automatico (ad esempio, una volta alla settimana o giù di lì).

Se si stanno spingendo i dati da un server a un altro server, non credo che il rischio di intercettazione delle password durante il transito sia altissimo. Certo, non è un rischio che devi assolutamente ignorare, ma l'intercettazione dei dati in queste situazioni è relativamente rara. Il rischio più elevato per intercettazioni è quando si inviano dati su una rete wireless o quando si inviano dati su una LAN contenente almeno una macchina compromessa / infetta. Sospetto che ci sia un rischio più elevato di furto delle password mentre sono a riposo, ad esempio perché qualcuno penetra in uno dei due endpoint o perché mancano i backup.

Non mi preoccuperei di essere onesto. La maggior parte delle applicazioni memorizza le loro password di database in testo semplice, non la vedo molto diversa. Se sei su un host condiviso, assicurati che solo il tuo account utente abbia accesso in lettura al file. Raccomando vivamente di utilizzare SFTP o FTPS, se non stai utilizzando uno di questi protocolli allora sei in attesa di essere violato .

Lasciando da parte il problema ENORME della sicurezza FTP e esaminando il problema della memorizzazione delle password, se hai bisogno di decrittografare la password (come opzionato semplicemente verificandolo con un valore hash memorizzato), affronti rapidamente il problema qualcuno che può accedere ai dati può probabilmente anche accedere alla chiave utilizzata per crittografare la password. L'unico modo per aggirare questo è mantenere copie della password cifrate usando una chiave univoca per ogni utente (cioè la password dell'utente) che è un PITA da gestire (sebbene ci siano alcune soluzioni di portafoglio digitale disponibili sullo scaffale).

Ci sono modi per mitigare il problema del cleartext FTP: l'utilizzo di una VPN è una soluzione molto ovvia, la limitazione dell'accesso a uno specifico indirizzo IP è molto meno efficace ma potrebbe comunque essere un'opzione praticabile se non rimane altra scelta. Ma nessuno dei due approcci si avvicina al sistema operativo di vantaggio utilizzando un protocollo sicuro.

Come hanno detto gli altri, la soluzione basata su FTP non è sicura, supponendo che tu abbia osservato la dovuta dilligence e ti sei tutelato chiarendolo, quindi suggerirei che l'unica opzione / responsabilità rimasta per te è progettare il tuo software in modo il più possibile della funzionalità è indipendente dal protocollo utilizzato per inviare i file, in modo da poter aggiungere facilmente il supporto per altri protocolli in un secondo momento.

C'è un piccolo vantaggio nella crittografia reversibile se un programma lo decodifica automaticamente. Se qualche idiota ha accesso in lettura allo script, probabilmente lo può anche eseguire e capire come decodificare la password. Certo, potrebbe impedire attacchi di tipo "sorella minore", ma non impedire alcuna sfida al tuo aggressore medio.

Personalmente, opterei per il testo in chiaro se non permetteranno di autenticarti in base alle chiavi, in aggiunta a un firewall che limita l'accesso.

Tuttavia, assicurati che le password che usi siano password casuali create proprio per questo scopo specifico. Ad esempio, una password di 16 simboli generata a caso diversa per ogni macchina. Non registrare mai una password / passphrase reale che usi altrove e ti impegni a memoria. Conserverei anche una copia della password in un elenco crittografato di cui è stato eseguito il backup in modo sicuro (ad esempio, keepassx con un db memorizzato su dropbox sincronizzato su più macchine, nonché backup controllato in versione).

Inoltre, come menzionato da Rook, assicurati di non utilizzare l'FTP ordinario su Internet aperto. Le password (e tutti i dati) sono inviate in chiaro che chiunque può origliare. Usa FTPS (FTP su SSL, simile a HTTPS è HTTP su SSL) o SFTP (trasferimento di file in stile FTP tramite SSH) o dispone di un tunnel VPN. Qualsiasi altra cosa è inaccettabile.

La password FTP serve per l'autenticazione sui server FTP di destinazione: la password sblocca l'accesso al servizio di archiviazione di questi server. In larga misura, questo è il loro problema, non il tuo.

Per essere più dettagliato, ogni volta che si invia un file di dati a un server, la riservatezza e l'integrità generali dei dati sono in parte responsabilità dell'amministratore del server. Non è possibile rendere i dati più sicuri di quelli che il peer è disposto a raggiungere e, insistendo su FTP con password e dati inviati in chiaro, gli amministratori dei server dimostrano che non gliene importa molto. La password che ti danno è una delega di responsabilità: ti concede un accesso e può richiedere alcune misure di protezione aggiuntive, ma se lo fanno non , allora non è il tuo ruolo di insistere indebitamente sull'argomento. Come si suol dire, non cercare di essere più cattolico del Papa. Sollevando la questione dell'insicurezza dell'FTP, hai adempiuto al tuo dovere di avvertire gli incauti; da quel momento, spetta a loro seguire l'argomento.

In pratica, potresti voler adottare alcune misure per evitare di perdere le password dalla tua parte, ad es. legge la protezione del file di configurazione che li contiene. Questo non è in realtà per rendere il sistema più sicuro, ma piuttosto per evitare di diventare il capro espiatorio se (quando) il sistema viene violato. È quindi necessario dimostrare che la fine del protocollo non era il punto più debole, e dal momento che FTP non ha crittografia e utilizza password non crittografate, non è difficile; la crittografia dalla tua parte sarebbe esagerata. Inoltre, se il sistema dalla tua parte deve procedere senza supervisione, significa che qualsiasi crittografia applicata alle password può essere annullata automaticamente dalla tua macchina, quindi qualsiasi crittografia applicata non sarebbe, teoricamente, più strong delle normali restrizioni di accesso in lettura sulla configurazione File. Quindi il mio consiglio è: non preoccuparti della crittografia della password, ti darebbe molta più complessità della reale sicurezza extra, e comunque non è la parte più debole del tuo sistema.

Naturalmente, potrebbe essere necessario chiedersi se si desidera veramente trasferire i dati potenzialmente sensibili su server FTP di terze parti di cui hanno dimostrato gli amministratori, rifiutando di passare a un protocollo più sicuro come SFTP , una quantità piuttosto spiacevole di incuria per quanto riguarda i problemi di sicurezza. Dipende tutto dal fatto che i dati che vuoi spingere siano davvero sensibili o meno.