Non so da dove vieni. Prima di tutto la sua opinione è contraria alla best practice del settore considerata come definita dal NIST. Inoltre il tuo manager si sbaglia pericolosamente. Maggiore è il numero di utenti, maggiori sono le 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:

• Facebook
• Gmail
• Linkedin

Un'altra ragione che puoi spiegare da un punto di vista aziendale è il rischio di danni all'immagine / al marchio quando ricevi pubblicità negativa . Per darti un esempio Adobe ha utilizzato una cattiva implementazione per l'archiviazione delle password che porta allo stesso problema che stai riscontrando ora: il valore risultante dall'hashing (nel caso di Adobe utilizzava la crittografia anziché l'hashing) la password era la stessa per diversi utenti se stavano utilizzando la stessa password (nel loro caso a causa del mancato utilizzo di 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 in vigore, oggigiorno la direzione può essere ritenuta personalmente responsabile se si accerta che è stata negligente quando si tratta di proteggere i dati privacy (se vengono utilizzate password violate per ottenere dati personali degli utenti, ad esempio). Inoltre, a seconda del tipo di informazioni archiviate, finanziarie, mediche, delle carte di credito, potrebbero essere applicate regole diverse che possono comportare anche altri tipi di multe.

Questo è qualcosa che potrebbe non essere rilevante per l'hashing diretto della password, ma potrebbe tornare utile se il tuo manager prende ulteriori decisioni sbagliate. Quindi assicurati di fare copie delle email in cui spieghi chiaramente il problema e salva anche la risposta dei tuoi manager. (solo per coprirti il ​​culo)

Il fatto che non stai usando i sali probabilmente significa anche che non stai usando un algoritmo di hashing corretto, poiché questi spesso si occupano della generazione dei sali e dell'esecuzione di una quantità di iterazioni . I tre algoritmi accettati sono:

• PBKDF2
• bcrypt
• scrypt

Lo scopo principale di salts è 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 univoche o meno.

Senza sali, l'attaccante può semplicemente scorrere il suo elenco di possibili password, calcolare l'hash per ciascuna e quindi controllare se il risultato corrisponde a gli hash memorizzati. Quindi è richiesto un solo calcolo per ipotesi.

Con salts, l'attaccante deve scorrere la sua lista per ogni utente, perché non può riutilizzare i risultati. Questo lo costringe a fare un calcolo per ipotesi e per utente. Ciò aumenta notevolmente i costi dell'attacco.

Ma come ha già detto Lucas, il vero problema qui è che non stai usando un algoritmo adeguato. I sali sono solo un aspetto dell'hashing delle password.

La "migliore" controargomentazione dipende da ciò che stai cercando di ottenere.

Se vuoi solo avere ragione scientificamente, allora è sufficiente dire che i sali non sono, e non lo sono mai stati, un metodo per far fronte a due utenti distinti che scelgono la stessa password. In particolare perché due utenti a cui capita di scegliere la stessa password non è un problema per cominciare, quindi non c'è nulla da risolvere. I sali servono per evitare attacchi paralleli, incluso 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 possono essere in torto o almeno non completamente informate. Ciò che citi dal tuo manager tende a dimostrare che è completamente incompetente sull'argomento e anche convinto di padroneggiarlo completamente. Se vuoi convincere quel manager che ha torto, allora, buona fortuna. Ciò che le persone temono di più è ammettere, anche implicitamente, di aver detto qualcosa di stupido.

Se desideri che la tua organizzazione passi effettivamente all'hashing della password corretto (leggi questo), ciò che potresti essere in grado di fare è convincere altre persone che ciò che il manager ha appena detto è puro senza senso, che non ha nemmeno abbastanza senso essere effettivamente sbagliato. Se il manager viene isolato, può chiudere un occhio sull'implementazione di un 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 le aree di influenza britannica come il New England), gli incontri di lavoro mirano a evitare scontri e diluire le responsabilità, quindi dovresti diffondere un po 'di paura, incertezza e dubbio: assicurati di sottolineare che il tuo concorrenti stanno passando agli hash salati e non facendo lo stesso si corre il rischio di perdere una parte di mercato. Nell'Europa meridionale, gli incontri sono battaglie rituali per stabilire la gerarchia, quindi urla, ringhia, minaccia e usa il sarcasmo per ottenere il sostegno della folla: non vinci avendo ragione , ma essendo assertivo .

Uno dei tipi di argomenti più efficienti, in generale, è l'appello all'autorità. Nella pubblicazione speciale NIST SP800-118 (attualmente in bozza), si può vedere:

Un altro esempio di debolezza dell'algoritmo hash è che alcuni algoritmi non usano il salting.

"No salt" = "debolezza". Lo dice il NIST. Chi è questo manager che pensa di essere più intelligente del NIST?

In un certo senso, se stai discutendo sul sale, hai già perso la barca. Lo stato dell'arte per quanto riguarda la sicurezza dell'archiviazione delle password va ben oltre la questione del "sale o non sale" e da allora è passato al conteggio delle iterazioni.

inizia con le basi. Ecco una risposta che ho scritto poco fa che è stata sorprendentemente popolare. Spiega perché il sale è migliore, e molte persone hanno detto che ha fatto clic su qualcosa dove altre spiegazioni sono cadute piatte. È più o meno quello che chiedi: mostralo al tuo capo se pensi che possa servire a qualcosa:

Perché gli hash salati sono più sicuri?

Ma il punto importante è l'ultimo fatto lì. Cioè, conservare un hash SHA1 salato e definirlo 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 di forza bruta più velocemente di quanto ci vorrebbe per spiegare cosa stai facendo.

Ora l'obiettivo è costringere l'attaccante a risolvere il problema migliaia o centinaia di migliaia di volte solo per indovinare. È qui che compare PBKDF2 (con indosso il completo e la cravatta rilasciati dal NIST), così come scrypt e gli amici (che sembrano trasandati ma potenti).

Quale algoritmo scegli non è davvero la chiave. Risolvono tutti più o meno lo stesso problema, solo in modi diversi con accenti diversi. Ma devi usare qualcosa : un algoritmo che rende difficile forzare anche una singola password. Il motivo è semplice: è lo standard del settore, è misurabile e dimostrabilmente più sicuro e non ci sono costi significativi per il suo utilizzo. Metti insieme questi fattori e diventa subito evidente che se non lo fai, puoi essere considerato negligente in caso di violazione.

L'argomento migliore è estrarre un elenco delle password più comuni e mostrare che circa l'1% dei tuoi utenti sceglierà "123456". Il secondo migliore sarebbe quello di estrarre un ' analisi della fuga di password per un sito di grandi dimensioni e mostrare che solo circa la metà dei tuoi utenti riuscirà a trovare una password univoca.

Dovresti fare due punti:

• L'uso di un salt riduce il valore di un file rubato contenente password con hash. Questo è vero indipendentemente dalla lingua o dalle lingue parlate dagli utenti del sistema, perché un utente malintenzionato che ha una tabella arcobaleno per il tuo algoritmo di hashing può usarla per invertire la password con hash indipendentemente dalla lingua madre della persona che l'ha scelta password.

• L'utilizzo di un salt è quasi gratuito. Non ti guadagna quasi nulla escluderlo, e anche nella stima corrente del tuo manager escludendolo è solo "probabile" che non causi un serio problema di sicurezza. Pertanto, usalo.

C'è un'obiezione che il tuo manager potrebbe sollevare contro il primo punto, ma spero non possa: "stiamo usando il nostro algoritmo di hashing personalizzato, quindi non c'è pericolo che esista un tavolo arcobaleno ". In tal caso, devi anche giustificare l'utilizzo di un algoritmo di hashing delle password standard.

Trovo anche:

[gli utenti ] hanno tutti linguaggi nativi diversi

per essere una strana ipotesi da fare su un sistema. Se ti affidi a un presupposto per la tua analisi di sicurezza, il tuo sistema diventa insicuro (o, in ogni caso, non valutato per la sicurezza) non appena il presupposto viene infranto. Quindi, dopo aver fatto affidamento su questo presupposto per la sicurezza, è necessario imporre che non ci siano due utenti del prodotto con la stessa lingua madre . Perché mai qualcuno dovrebbe voler limitare il proprio sistema in quel modo, e in particolare come sarà più facile far rispettare questa restrizione che usare un sale?

Tuttavia, in questo caso quell'ipotesi non porta nemmeno alla conclusione il tuo manager fa che il sale non sia necessario (per il motivo che ho dato sopra). Quindi la domanda se l'ipotesi possa essere mantenuta è abbastanza irrilevante di fronte al fatto che non aiuta!

Infine, per tua informazione, c'è una ragione specifica per cui il mio primo punto sopra contraddice l'analisi del tuo manager:

è improbabile che utilizzi la stessa password

è un'analisi errata della debolezza affrontata da Salt. Non importa per l'attaccante se due utenti del sistema hanno o meno la stessa password, a meno che l'attaccante non sia uno di quei due utenti e quindi conosca la password che condividono. I sali non difendono solo da questo attacco, ma difendono anche dagli attacchi del tavolo arcobaleno. Quindi, anche se questo insolito attacco con la stessa password da parte 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 con spiegazioni tecniche. Se il tuo manager reagisce positivamente alle spiegazioni tecniche, scegli prima una delle risposte.

Se vuoi passare dal lato delle competenze trasversali, puoi provare alcune cose:

• La cosa più importante da ricordare: il tuo capo è il tuo capo. Non arrabbiarti con lui, altrimenti sarai lo sfortunato.
• Cerca di non fargli domande a cui non può rispondere. Poni invece domande indirette sotto forma di frasi semplici.
• Prova a capire il suo punto di vista e i suoi argomenti.
• Applica parafrasi.
• Non ridere mai.
• Non essere mai scortese.
• Leggi il libro di Dale Carnegie "Come conquistare amici e influenzare le persone".

Una finestra di dialogo di esempio potrebbe essere simile a questa (tieni presente che io ' Non sono un madrelingua inglese):

Capo: "Non abbiamo bisogno di sali."
Tu: "Non abbiamo bisogno di questa protezione aggiuntiva".
Capo: "Sì, i nostri utenti non riutilizzano la stessa password."
Tu: "Le password complesse sono già sicure."
Boss: "Esatto".
Tu: "Va bene, ho capito. I nostri utenti proteggono la password e noi viviamo senza sali".
Capo: "Sì, forse non tutti gli utenti ..."
Tu: sorridi

O in questo modo:

Capo: "Non abbiamo bisogno di sali".
Tu: "Il vantaggio di usare i sali non vale lo sforzo."
Boss: "È corretto."
Tu: "Quindi cancelliamo il sale dall'elenco delle attività e procediamo con il resto."
Boss: "Bene, siamo già in ritardo sulla pianificazione."
Tu: "Se rispettassimo il programma in un altro modo, possiamo implementare il sale".
Boss: "No, non capisco il concetto di sale."
Tu: "Quella roba crittografica è sempre difficile da capire."
Boss: "Anche quando ho letto un articolo, non ho avuto la minima idea."
Tu: "Il che ti fa pensare che sia un grande sforzo."
Boss: "Sì, perderemo due giorni o giù di lì."
Tu: "Con l'aiuto di un framework posso farlo in 2 ore."
Boss: "Davvero?"
Tu: sorridi

Nota che non ci sono punti interrogativi. Il capo non è mai sotto pressione per rispondere a domande a cui potrebbe non conoscere la risposta.

Sfortunatamente è abbastanza difficile applicare tali tecniche se non l'hai mai fatto prima.

Se questo approccio non funziona neanche bene, c'è un'altra opzione:

Basta implementarla. Non dovrebbe essere uno sforzo eccessivo e il tuo capo probabilmente non lo noterà, tranne che sta facendo la revisione del codice o guardando le tabelle del database.

Basta inserire alcuni hash (forse la sua stessa password) in Google. Molto probabilmente restituirà la password. Il suo hashing debole è come nessun hashing.

https://www.google.de/search?q=a94a8fe5ccb19ba61c4c0873d391e987982fbbd3

In caso contrario convincerlo a cercare un nuovo lavoro ...