Cosa fare quando la tua azienda non cripta le password

L'approccio calmo che suggerisci sarebbe il migliore. Sottolineando che quando questi dati vengono esposti, la maggior parte degli utenti sarà vulnerabile al furto di identità dovuto al riutilizzo della password. Questo sarebbe un buon momento per sottolineare che questo è lo stesso problema che ha colpito 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 username / password siano considerati uguali a dati CC, informazioni personali, ecc. Sebbene possa dipendere dalle informazioni che tu abbia sempre per i tuoi utenti. Io non sono un avvocato e questi aspetti sarebbero meglio sollevati nella tua rivelazione e dovrebbero essere portati al dipartimento legale della tua azienda per determinare la legalità.

link

Inoltre, hai a disposizione questo XKCD:

Dipende davvero dal pubblico in cui stai cercando di avvicinarti a questo. Ho lavorato in aziende con gravi problemi di sicurezza, come si sta affermando, ma si sono rifiutati di ascoltarlo fino a quando l'ho mostrato loro.

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

La prossima cosa che dovresti fare, se possibile, è dimostrarlo. Se riesci a sopportare questo sistema in un ambiente di test, fallo. Quindi dimostra di fronte a loro il tipo di impatto che puoi avere sul sistema dal lato client dell'applicazione. Anche con la gente di tecnologia questo ha dimostrato di essere abbastanza convincente per me (anche se di solito non recitavano nei miei casi).

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

Se come dici tu hai contratto per mantenere il loro server, sicuramente questo contratto deve includere compiti di descrizione del lavoro come garantire l'integrità, la sicurezza e la disponibilità del sistema operativo, software applicativo e tutti i dati, ecc ?! Se c'è anche un vago accenno al fatto che il contratto si aspetta (e ti ritenga responsabile) per assicurarsi che il server sia sicuro, non perderei tempo a mettere insieme i casi aziendali e fare un buon lavoro per assicurarmi che i problemi siano risolti (prendendo un backup prima e dopo, mantenendo una cronologia delle versioni del codice cambia).

Non mi aspetto che un cambiamento come questo richieda più di una mattina di lavoro e se chiedono a cosa hai dedicato il tuo tempo di lavoro puoi tenere un diario per spiegare e giustificare le tue azioni. A condizione che lavori nell'ambito del tuo contratto non dovrebbero esserci problemi qui. A volte andare pazzi per la sicurezza di fronte ai responsabili delle decisioni provoca il panico o nel peggiore dei casi crea un'opportunità per loro di dire che non si preoccupano di questi problemi quindi non aggiustarlo, nel frattempo il contratto ti tiene ancora responsabile in caso di una falla! Forse questo non è sempre l'approccio più business-friendly, ma la mia etica professionale non mi permetterebbe di lasciare password non crittografate in qualsiasi sistema che abbia mai avuto la responsabilità di averlo fatto venire alla mia attenzione.

Dall'esperienza personale che tendo a trovare ogni volta che comincio a lavorare per un nuovo datore di lavoro o cliente, discutere anticipatamente gli scenari e le aspettative può far risparmiare un sacco di stress alla tua parte, ad esempio: se trovo problemi di sicurezza che posso risolvere sono sei felice per me di andare avanti e completare questo lavoro senza venire da te ogni volta, solo informandoti di sospetti violazioni / incidenti? Quasi sempre diranno di sì, perché dal loro punto di vista non sono interessati a preoccuparsi della sicurezza o del computer - è per questo che ti hanno assunto! Forse questo non risponde alla domanda nel modo in cui ti aspettavi, ma spero che dia spunti di riflessione. Vi auguro il meglio e speriamo che il problema venga risolto!

Sicuramente se il cambiamento dell'indirizzo email del cliente sta già accadendo e questo è considerato un problema, allora anche la possibilità di cambiare la password è un problema.

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

Ovviamente se possono, o se (nell'evento improbabile ) di non aver completamente protetto il DB, allora sicuramente si dovrebbe fare la crittografia delle password - come si fa? Inseritelo nello stesso contesto in cui si presenta il problema di "avere indirizzi email aggiornati". Se questo richiede che l'applicazione cambi, e se questo è un problema "troppo difficile" è un'altra questione che deve essere sollevata con loro. Guarda il codice e vedi quanto il costo di cambiarlo sarà prima di prendere la soluzione suggerita per loro.