Cosa fare quando la tua azienda non crittografa le password

sfondo

Sono stato assunto per aiutare un'azienda a mantenere il proprio server. Lavoro su alcuni progetti PHP minori, ma mi occupo anche dei problemi di prestazioni e, recentemente, eseguo la scansione dei log per gli hacker.

Questi ragazzi hanno eseguito il loro server per un po 'di tempo e hanno quella che definirei un'applicazione legacy nelle sue ultime fasi. Usa virgolette, variabili globali (che permettono $iddi essere sovrascritte da $_GET['id']), usa .htaccess come unica sicurezza in alcuni casi, lo chiami. Un incubo per la sicurezza e la programmazione.

In passato siamo stati hackerati, principalmente con iniezioni di SQL, che eseguivano SLEEP(99999999)comandi e fungevano da attacco DOS. Fortunatamente non gestivano "tavolini bobby",

XKCD: http://xkcd.com/327/

Quindi ho riscritto le loro vulnerabili istruzioni SQL da mysql_query()(non mysqli) a transazioni PDO. Sto anche analizzando le domande per SLEEPe UNION, che non usiamo ma le iniezioni hanno. Fin qui tutto bene.

Ultimo numero

Recentemente ci è stato detto che i record stanno cambiando nel DB per gli utenti, come i loro indirizzi e-mail presumibilmente creati dagli spammer.

Ho notato che le loro colonne non avevano una last_modifiedcolonna, quindi non eravamo nemmeno in grado di sapere quando sarebbero state cambiate, figuriamoci da chi. Ho aggiunto quella colonna, ma è appena un primo passo.

Quando stavo guardando questo tavolo, ho notato che le password non venivano né salate, né neppure cancellate, ma salvate come testo in chiaro.

Comunicazione del cliente

Come posso affrontarli sull'intera situazione, come appaltatore, senza agitare le braccia come un pazzo? Qualche consiglio? Stavo pensando a un approccio calmo di,

    NUMERO 1
        Sinossi
        Perché questo è un problema
        Cosa può succedere se questo non viene risolto
        Correzione suggerita

    NUMERO 2
        Sinossi
        Perché questo è un problema
        Cosa può succedere se questo non viene risolto
        Correzione suggerita
        

L'approccio calmo che suggerisci sarebbe il migliore. Ricordando che quando questi dati vengono esposti, la maggior parte dei tuoi utenti sarà vulnerabile al furto di identità a causa del riutilizzo della password. Sarebbe un buon momento per sottolineare che si tratta dello stesso problema che ha interessato Target (supponendo che la società non sia Target). E il tuo manager dovrebbe essere piuttosto ricettivo a cambiare questo.

Per quanto riguarda la legalità con i dati, non credo che il nome utente / le password siano considerati uguali ai dati CC, alle informazioni personali, ecc. Sebbene possa dipendere da qualsiasi informazione tu abbia per i tuoi utenti. Non sono un avvocato e questi aspetti dovrebbero essere meglio evidenziati nella tua rivelazione e dovrebbero essere portati al dipartimento legale della tua azienda per determinare la legalità.

https://en.wikipedia.org/wiki/Information_privacy_law

E hai questo XKCD anche per aiutarti:

Dipende molto dal pubblico in cui stai cercando di avvicinarti a questo. Ho lavorato in aziende con gravi problemi di sicurezza come te affermi, ma si sono rifiutati di ascoltarlo fino a quando non glielo ho mostrato.

Un approccio, se possibile, è quello di mettere insieme fondamentalmente ciò che si intende fare, così come dettagliare ciò che è già probabilmente accaduto in questi hack. Se il tuo pubblico non è tecnico, probabilmente dovrai indicare i costi aziendali che questi compromessi possono avere. Ovviamente gli account compromessi riducono la credibilità nel sistema e percepiscono il valore del cliente per il tuo prodotto. Per non parlare di un sistema compromesso con password in chiaro e indirizzi e-mail per gli utenti che possono causare gravi increspature.

La prossima cosa che dovresti fare, se possibile, è dimostrarlo. Se riesci a sostenere questo sistema in un ambiente di prova, fallo. Quindi dimostrare di fronte a loro il tipo di impatto che si può avere sul sistema dal lato client dell'applicazione. Anche con le persone tecnologiche questo ha dimostrato di essere abbastanza convincente per me (anche se di solito non hanno agito nei miei casi).

Naturalmente, come hai detto, devi spiegare se qualcosa quali misure dovrebbero essere prese e una stima dello sforzo per raggiungere questo obiettivo. Li aiuterà a giustificare il costo, anche se alcuni posti semplicemente non se ne cureranno comunque. Almeno puoi liberare la tua coscienza e andare avanti sapendo che hai provato.

Se, come dici, sei stato incaricato di mantenere il suo server, sicuramente questo contratto deve includere nella descrizione delle mansioni attività come garantire l'integrità, la sicurezza e la disponibilità del sistema operativo, del software applicativo e di tutti i dati ecc. Se c'è anche un vago indizio che il contratto si aspetta (e ti ritiene responsabile) per assicurarsi che il server sia sicuro, allora non perderei tempo a mettere insieme i casi aziendali e farei un buon lavoro assicurandomi che i problemi vengano risolti (prendendo un backup prima e dopo, mantenendo una cronologia delle versioni delle modifiche del codice).

Non mi aspetto che un cambiamento come questo richieda più di una mattinata di lavoro e se ti chiedono su cosa hai passato il tuo tempo a lavorare, puoi tenere un diario per spiegare e giustificare le tue azioni. A condizione che tu stia lavorando nell'ambito del tuo contratto, non ci dovrebbero essere problemi qui. A volte impazzire tutta la sicurezza di fronte ai responsabili delle decisioni provoca panico o, nel peggiore dei casi, crea un'opportunità per loro di dire che non si preoccupano di questi problemi, quindi non risolverli, nel frattempo il tuo contratto ti ritiene responsabile in caso di una falla! Forse questo non è sempre l'approccio più favorevole alle imprese, ma la mia etica professionale non mi permetterebbe di lasciare password non crittografate in qualsiasi sistema di cui sia mai stato responsabile per averlo portato alla mia attenzione.

Per esperienza personale, tendo a trovare ogni volta che inizio a lavorare per un nuovo datore di lavoro o cliente, discutere di scenari e aspettative in anticipo può risparmiare molto stress da parte tua, ad esempio: se trovo problemi di sicurezza che posso risolvere sei felice per me per andare avanti e completare questo lavoro senza venire ogni volta da te, avvisandoti solo di sospette violazioni / incidenti? Quasi sempre diranno sì a questo perché dal loro punto di vista non sono interessati a preoccuparsi della sicurezza o delle cose del computer - ecco perché ti hanno assunto! Forse questo non risponde alla domanda come ti aspettavi, ma spero che dia spunti di riflessione. Ti auguro tutto il meglio e spero che il problema venga risolto!

Sicuramente se la modifica dell'indirizzo e-mail del cliente sta già avvenendo e questo è considerato un problema, allora anche la possibilità di cambiare le password è un problema.

Ora, se hai protetto sufficientemente il DB per evitare che ciò accada in futuro, allora la possibilità che chiunque possa modificare la password dell'utente è fissata in modo simile e devi solo considerare se qualcuno può leggere la password ora.

Ovviamente se possono, o se (nel caso improbabile ) di non aver completamente protetto il DB, allora sicuramente dovrebbe essere fatta la crittografia delle password - come farlo? Inseriscilo nello stesso contesto del problema "avere indirizzi email aggiornati". Se questo richiede che l'applicazione cambi, e se si tratta di un problema "troppo difficile" è un'altra questione che deve essere sollevata con loro. Guarda il codice e vedi quanto sarà il costo della modifica prima di prendere la correzione suggerita per loro.