Il mio manager dice che non è necessario scaricare le password perché è improbabile che le persone utilizzino la stessa password perché hanno tutte lingue diverse, oltre ai siti Web in cui sono attive. Qual è il miglior contro-argomento per questo?
Non sono sicuro da dove vieni. Prima di tutto la sua opinione è contraria alla best practice del settore considerata come definita da NIST . Inoltre il tuo manager è pericolosamente sbagliato. Maggiore è il numero di utenti, maggiore è la probabilità di ottenere le stesse password per più utenti. Anche le seguenti società lo fanno e sono abbastanza convinto che abbiano una base di utenti globale più ampia del tuo sito web:
Un altro motivo che puoi spiegare da una prospettiva aziendale è il rischio di danno di immagine / marchio quando ricevi pubblicità negativa . Per fare un esempio, Adobe ha utilizzato una cattiva implementazione per l'archiviazione delle password che ha portato allo stesso problema che si ha ora: il valore risultante dall'hash (nel caso di Adobe stavano usando la crittografia piuttosto che l'hashing) la password era la stessa per diversi utenti se stavano usando la stessa password (nel loro caso a causa di non usare un IV durante l'esecuzione della crittografia simmetrica, ma questo non è rilevante). Ciò ha causato una massiccia tempesta di pubblicità negativa, dopotutto una società di internet dovrebbe aderire a qualcosa di semplice come l'hashing della password no? Il costo finanziario derivante da tale pubblicità negativa può essere significativo.
Inoltre, a seconda del paese in cui vivi e delle leggi impiegate, in questi giorni la gestione può essere ritenuta personalmente responsabile se si determina che sono stati negligenti quando si tratta di proteggere la privacy dei dati (in caso di crack le password vengono utilizzate per ottenere dati personali degli utenti, ad esempio). Inoltre, a seconda del tipo di informazioni memorizzate, finanziarie, mediche, carte di credito, possono essere applicate regole diverse che possono comportare anche altri tipi di sanzioni.
Questo è qualcosa che potrebbe non essere rilevante per l'hashing della password direttamente, ma potrebbe rivelarsi utile se il tuo manager prende ulteriori decisioni sbagliate. Quindi assicurati di fare copie delle e-mail in cui spieghi chiaramente il problema e salva anche la risposta del tuo manager. (solo per coprirti il culo)
Il fatto che non si stiano utilizzando i sali probabilmente significa che non si sta utilizzando un algoritmo di hashing corretto, poiché questi spesso si prendono cura dei sali generatori e eseguono una quantità di iterazioni. I tre algoritmi accettati sono:
Lo scopo principale dei sali è impedire a un utente malintenzionato di salvare il lavoro confrontando un singolo hash calcolato con tutti gli hash memorizzati. Questo problema è indipendente dal fatto che le password siano o meno uniche.
Senza i sali, l'utente malintenzionato può semplicemente consultare l'elenco delle possibili password, calcolare l'hash per ciascuna e quindi verificare se il risultato corrisponde a uno degli hash memorizzati. Quindi è richiesto un solo calcolo per ipotesi.
Con i sali, l'attaccante deve passare attraverso la sua lista per ogni utente, perché non può riutilizzare i risultati. Questo lo costringe a fare un calcolo per ipotesi e per utente. Questo aumenta enormemente i costi dell'attacco.
Ma come già detto Lucas, il vero problema qui è che non stai usando un algoritmo adeguato. I sali sono solo un aspetto dell'hash delle password.
Il "migliore" contro-argomento dipende da ciò che stai cercando di ottenere.
Se vuoi solo essere scientificamente corretto, allora è sufficiente dire che i sali non sono, e non sono mai stati, un metodo per far fronte a due utenti distinti che scelgono la stessa password. In particolare perché due utenti che capita di scegliere la stessa password non è un problema, quindi non c'è niente da sistemare. I sali servono per evitare attacchi paralleli, compreso l'uso di tabelle precalcolate. La mancanza di sali era il peccato capitale di LinkedIn .
Ora avere ragione ha un effetto solo sulle persone che sono pronte a riconoscere che potrebbero essere sbagliate o almeno non completamente informate. Quello che citi dal tuo manager tende a dimostrare che è completamente incompetente sull'argomento, e anche convinto di essere totalmente padrone di esso. Se vuoi convincere quel manager che ha torto, allora, buona fortuna. Ciò che la gente teme di più è ammettere, anche implicitamente, che hanno detto qualcosa di stupido.
Se vuoi che la tua organizzazione passi effettivamente all'hash della password corretta (leggi questo ), quindi ciò che potrebbe essere in grado di fare è convincere altre persone che ciò che il manager ha appena detto è pura incomprensibilità, che nemmeno avere abbastanza senso per essere veramente sbagliato. Se il manager viene isolato, può chiudere un occhio sull'implementazione del corretto hashing della password, senza, ovviamente, mai riconoscerlo. Anche in questo caso, l'argomento scientificamente corretto non è necessariamente il più efficiente. In Nord America (in particolare aree influenzate da inglesi come il New England), gli incontri di lavoro riguardano l'evitare scontri e la diluizione delle responsabilità, quindi dovresti diffondere alcuni paura, incertezza e dubbi : ricorda che i tuoi concorrenti stanno passando agli hash salati, e non fare lo stesso comporta il rischio di perdere alcune quote di mercato. Nell'Europa meridionale, gli incontri sono battaglie rituali per stabilire la gerarchia, quindi gridare, ringhiare, minacciare e usare il sarcasmo per vincere il sostegno del pubblico: non si vince essendo giusto , ma essendo assertivo .
Uno dei tipi più efficaci di argomenti, in generale, è l'appello all'autorità. In Pubblicazione speciale NIST SP800-118 (attualmente in bozza), uno può vedere:
Another example of a hash algorithm weakness is that some algorithms do not use salting.
"Nessun sale"="debolezza". Il NIST dice questo. Chi è questo manager che pensa di essere più intelligente del NIST?
In un certo senso, se stai litigando per il sale, hai già perso la barca. Lo stato dell'arte per quanto riguarda la sicurezza dell'archiviazione delle password va ben oltre la domanda "sale o non sale" e da allora è passata al conteggio delle iterazioni.
Ma iniziamo con le basi. Ecco una risposta che ho scritto poco fa che era sorprendentemente popolare. Spiega perché il sale è migliore, e molte persone hanno detto di aver fatto clic su dove le altre spiegazioni sono cadute. È più o meno quello che stai chiedendo - mostralo al tuo capo se pensi che andrà bene:
Perché gli hash salati sono più sicuri?
Ma il punto importante è l'ultimo fatto lì. Vale a dire, memorizzare un hash SHA1 salato e chiamarlo buono non è più considerato responsabile. La potenza di calcolo ha raggiunto il punto in cui miliardi di hash al secondo non sono più teorici, permettendoti di attraversare l'intero spazio a 32 bit di un attacco a forza bruta più veloce di quello che servirebbe per spiegare cosa stai facendo.
Ora l'obiettivo è di costringere l'attaccante a risolvere il problema migliaia o centinaia di migliaia di volte solo per fare una congettura. Ecco dove PBKDF2 si presenta (indossando giacca e cravatta con il marchio NIST), così come scrypt e amici (sembra trasandato ma potente).
Quale algoritmo scegli non è realmente la chiave. Tutti risolvono grosso modo lo stesso problema, solo in modi diversi con accenti diversi. Ma devi usare qualcosa - qualche algoritmo che rende difficile la forza bruta anche di una singola password. Il motivo è semplice: è lo standard del settore, è misurabile e dimostra- bile in modo più sicuro e non comporta costi significativi per l'utilizzo. Metti insieme questi fattori e diventa subito evidente che se non lo fai, allora puoi essere considerato negligente in caso di violazione.
L'argomento migliore è estrarre un elenco delle password più comuni e mostrare che circa 1 Il% dei tuoi utenti selezionerà "123456". Il secondo migliore sarebbe tirare fuori una perdita di password analisi per un sito di grandi dimensioni e mostra che solo circa la metà dei tuoi utenti riuscirà a trovare una password univoca.
Devi creare due punti:
L'uso di sale riduce il valore di un file rubato contenente password con hash. Questo è vero a prescindere dalla lingua parlata dagli utenti del sistema, perché un utente malintenzionato che ha una tabella arcobaleno per l'algoritmo di hashing può utilizzarlo per invertire la password con hash a prescindere dalla lingua nativa della persona che ha scelto quella password.
L'uso di un sale è quasi gratuito. Non ti fa quasi nulla da escludere, e anche nella stima attuale del tuo manager, escludendolo, è solo "probabile" non causare un serio problema di sicurezza. Pertanto, usalo.
C'è un'obiezione che il tuo manager potrebbe sollevare contro il primo punto, ma spero di non poterlo fare: "stiamo usando il nostro algoritmo di hashing personalizzato, quindi non c'è pericolo che esista una tabella arcobaleno per esso". In tal caso, devi anche per utilizzare l'algoritmo di hashing della password standard.
Trovo anche:
[the users] all have different native languages
essere un'assunzione bizzarra da fare su un sistema. Se si basa su un'ipotesi per l'analisi della sicurezza, il sistema diventa insicuro (o comunque non valutato per la sicurezza) non appena viene interrotta l'ipotesi. Quindi, avendo fatto affidamento su questo assunto per motivi di sicurezza, è quindi necessario far sì che non ci siano due utenti del prodotto con la stessa lingua nativa . Perché mai qualcuno vorrebbe limitare il proprio sistema in questo modo, e in particolare in che modo imporre questa restrizione sarà più semplice rispetto all'utilizzo di un sale?
Tuttavia, in questo caso questa ipotesi non porta nemmeno alla conclusione che il tuo manager fa che il sale non sia necessario (per la ragione che ho dato sopra). Quindi la domanda se l'assunzione può essere mantenuta è abbastanza irrilevante di fronte al fatto che non aiuta!
Per finire, c'è una ragione specifica per cui il mio primo punto sopra contraddice l'analisi del tuo manager:
not likely to use the same password
è un'analisi imperfetta della debolezza che il sale affronta. Non è importante per l'utente malintenzionato se due utenti del sistema abbiano o meno la stessa password, a meno che l'autore dell'attacco non sia uno di questi due utenti e quindi conosca la password che condividono. I Sali non difendono solo da questo attacco, ma difendono anche dagli attacchi dei tavoli arcobaleno. Quindi, anche se questo insolito attacco con stessa password di uno dei tuoi utenti fosse impossibile sul tuo sistema, avresti comunque bisogno di sali.
Immagino che questo sia più un problema di persone che un problema tecnico. Pertanto è necessario rispondere con competenze trasversali piuttosto che spiegazioni tecniche. Se il tuo manager reagisce positivamente alle spiegazioni tecniche, scegli una delle risposte precedenti.
Se vuoi andare sul lato delle soft skills, puoi provare alcune cose:
Una finestra di esempio potrebbe apparire come questa (sii consapevole che non sono un madrelingua inglese):
Boss: "We don't need salts."
You: "We don't need that additional protection."
Boss: "Yes, our users don't reuse the same password."
You: "Strong password are already secure."
Boss: "That's right."
You: "Alright, I understand. Our users make the password secure and we just live without salts."
Boss: "Yeah, maybe not all users ..."
You: smile
O come questo:
Boss: "We don't need salts."
You: "The benefit of using salts is not worth the effort."
Boss: "That's correct."
You: "So we deleting the salt from the task list and go on with the rest."
Boss: "Right, we're already behind schedule."
You: "If we would meet the schedule another way, can we would implement the salt."
Boss: "No, I don't understand that salt concept."
You: "That cryptographic stuff is always hard to understand."
Boss: "Even when I read an article, I didn't get the clue."
You: "Which makes you think it's a lot of effort."
Boss: "Yes, we'll lose two days or so."
You: "With some help of a framework I can do it in 2 hours."
Boss: "Really?"
You: smile
Nota che non ci sono punti interrogativi. Il capo non è mai sotto pressione per rispondere a domande a cui potrebbe non essere in grado di rispondere.
Sfortunatamente è piuttosto difficile applicare tali tecniche se non l'hai mai fatto prima.
Se anche questo approccio non funziona bene, c'è un'altra opzione:
Basta implementarlo. Non dovrebbe essere troppo impegnativo e il tuo capo probabilmente non se ne accorgerà, tranne che sta eseguendo la revisione del codice o guardando le tabelle del database.