La vera risposta alla tua domanda è semplicemente non memorizzare le password lì se non puoi proteggerle adeguatamente.

"Il sistema non supporta algoritmi di hashing delle password adeguati" non è una scusa valida per compromettere il sicurezza dei tuoi utenti. O trova un modo per eseguire l'hashing corretto delle password utilizzando un algoritmo potente e configurato correttamente oppure non memorizzarle.

Ma per fornire una risposta diretta alla tua domanda: sì, qualcosa è meglio di niente. SHA-1 o SHA-2 è decisamente un miglioramento rispetto al testo in chiaro.

Per rispondere alla domanda "allora dove dovrebbero andare le password?" domanda - In base alla frase presumo che ci sia una nuova funzione / richiesta per il software che richiede al sistema di memorizzare le password.

Se il sistema non è in grado di memorizzare correttamente e in sicurezza le password (secondo i moderni standard di sicurezza), io (personalmente) rifiuterei la richiesta. Praticare intenzionalmente una scarsa sicurezza a causa di vincoli del sistema legacy o per placare un caso d'uso aziendale è una cattiva pratica di sicurezza. Informerei chiunque abbia fatto la richiesta che ho due opzioni praticabili:

1. Dobbiamo revisionare completamente il sistema a uno che supporti le moderne pratiche di sicurezza (come un corretto hashing crittografico della password).

2. Semplicemente non posso aggiungere la nuova funzione / richiesta al sistema esistente perché comprometterebbe la sicurezza.

Sì, un hash crittografico debole è meglio di nessun hash.

I motivi per l'hashing delle password sono, nel caso in cui il database della password venga rubato:

1. Impedisci all'autore dell'attacco di ottenere banalmente le password in chiaro.
2. Impedisci all'autore dell'attacco di sapere quali utenti hanno la stessa password (questo si ottiene assegnando a ciascun utente un salt univoco.

1 è una corsa agli armamenti: vuoi usare una funzione hash più grande e più lenta in modo che l'attaccante costi di più in elettricità per eseguire il cracking dell'hash a forza bruta. Una singola iterazione di SHA-1/2 è meglio di nessun hash perché l'attaccante deve eseguire un po ' cracking. Una singola iterazione di salted SHA-1/2 lo costringerà a fare un po' di cracking senza essere in grado di utilizzare pre-calcolati tabelle arcobaleno . Passare agli hash delle password più elaborati (argon2, bcrypt o il vecchio scrypt, pbkdf2) con un fattore di lavoro più elevato aumenterà ulteriormente i costi dell'elettricità del crack.

Utilizzando qualsiasi crittografia salata l'hash rapico (anche quelli non consigliati per le password, come SHA-1, SHA-2) darà i vantaggi di 2.

Fondamentalmente, PBKDF2 è solo SHA-1 iterato e salato / 2, quindi farei un po 'di ricerca su Google per le implementazioni di PBKDF2 e creerei il tuo wrapper attorno a SHA-1/2 che lo emula (o meglio, vado fino in fondo e implementa effettivamente PBKDF2).

Come altri hanno già detto, cerca di trovare un'implementazione autonoma forte nel linguaggio della tua piattaforma, se possibile.

Ma se non puoi usare un hash forte ... allora dovresti sicuramente ancora hash le password dei tuoi utenti, anche con un hash debole, perché anche un hash debole proteggerà una password complessa .

Quando strumenti come hashcat possono indovinare miliardi di password al secondo , gli hash deboli non proteggeranno le password deboli. Ma se uno dei tuoi utenti attenti alla sicurezza seleziona una password non crackabile come 'SDXBZsRVBKVnXznpLTBMIKhTX' o 'afferently-imitatee-snowmelt-heirdom-leeching' ... allora anche un hash debole come SHA1 metterà comunque quella password fuori dalla portata di una forza bruta attacco.

Usando anche un hash debole, puoi almeno consentire ai tuoi utenti esperti di proteggersi anche se il tuo sistema è debole . (E se hai la capacità di allungare - per utilizzare lo stesso algoritmo migliaia di volte di seguito - questo rallenterà anche l'aggressore).

Ma i tuoi utenti esperti non riutilizzerà le password, quindi anche questo ha un valore limitato (eccetto per gli utenti "semi-esperti" che hanno scelto password abbastanza forti da resistere alla forza bruta, ma potrebbero riutilizzare quella password altrove o usare uno schema di selezione della password analizzabile dall'uomo. .. quindi usare anche un hash debole proteggerà anche questi utenti).

La tua migliore opzione per tutti gli utenti è trovare un modo per utilizzare un hash forte.

[Modifica: l'OP ha aggiornato la domanda per indicare che è l'unico utente del sistema e può impostare una password arbitrariamente casuale (il che mi sembra piuttosto strano; non lo faccio conosco un sistema con una combinazione così strana di "Sono l'unico utente", "Posso scegliere solo tra pochi algoritmi di hashing" e "Tutti gli algoritmi di hashing sono deboli"). In ogni caso, questo rende la mia preoccupazione di proteggere le password deboli degli utenti generici irrilevante per questa domanda specifica. Altre risposte dovrebbero chiarire all'inizio delle loro risposte che stanno dando consigli che normalmente sarebbero piuttosto pessimi, ed è applicabile solo a questa domanda molto specifica.]

[Modifica 2: nota che "hash debole" non è la stessa cosa di "hash cattivo". Un esempio di hash errato potrebbe essere descritto (perché tronca le password a 8 caratteri). Quindi, anche se la tua password è complessa, un hash descrypt di 8 caratteri può essere forzato in 10 giorni o meno su un sistema di cracking di livello prosumer (6 GPU).]

SHA-2 in questo caso particolare è sicuro quanto PBKDF / scrypt / bcrypt. Le iterazioni sono inutili e dispendiose. Genera password ad alta entropia (256 bit) e dimentica KDF e persino sali.

In effetti, ha più senso usare SHA-2 rispetto a PBKDF perché non esiste un'implementazione della piattaforma esistente di l'algoritmo e "lanciare la tua crittografia" è un no-no.

Questa è un'affermazione abbastanza forte. L'essenza qui nella domanda è che l'OP ha il pieno controllo delle password che memorizza nel sistema e sa che sarà l'unico a memorizzare le password nel sistema.

Signal utilizza una costruzione chiamata HKDF nel suo algoritmo a doppio cricchetto, che essenzialmente applica l'algoritmo di hashing per una sola iterazione.

Perché va bene?

Le password KDF esistono precisamente per una ragione: le password a bassa entropia. La maggior parte delle persone non ricorderà una chiave a 128 o 256 bit generata da un CSRNG nelle loro teste. Oserei che la maggior parte delle persone possa ricordare al massimo una stringa casuale a 40 bit per un periodo di tempo abbastanza lungo da poterla utilizzare.

Praticamente tutte le funzioni hash (anche MD4, MD5 e SHA-1 , ma dal momento che hai detto di avere SHA-2 sulla piattaforma, siamo al sicuro qui) hai una funzione chiamata resistenza alla preimmaginazione, che è abbastanza buona per la tua applicazione poiché controlli tutte le password che vengono memorizzate sul tuo sistema. Ciò significa che è computazionalmente impossibile, dato un hash, generare qualcosa che abbia lo stesso hash.

Semplificando un po ', il modo più pratico per generare un'immagine preliminare per una di queste funzioni hash è mantenere provando input. Ci sono alcuni esempi di attacchi che funzionano leggermente meglio della forza bruta, ma sono totalmente irrealizzabili. Ora, se la password / chiave che hai scelto di inserire nella funzione hash ha solo 16 bit di entropia, questa proprietà di resistenza non ti farà molto, perché l'attaccante sarà in grado di provare tutti i 65536 input diversi che avresti potuto inserire.

Perché il controllo della password è importante

Pensa meno alle cose che stai inserendo come "password" ma più come chiavi crittografiche. Finché stai eseguendo l'hashing delle chiavi che hanno un'entropia maggiore o uguale al numero di bit in uscita dalla tua scelta della funzione hash (per SHA-256, sono 256 bit), allora stai perfettamente bene solo eseguendo un'iterazione dell'hash sopra per impedire l'estrazione della chiave. La resistenza all'immagine precedente dell'hash combinata con l'elevata entropia della tua chiave significa che un attaccante semplicemente non può indovinare il valore che hai inserito. Non c'è bisogno di migliaia di iterazioni o litigare con il lato commerciale o ragionare su un attacco astratto per non - capi così ricettivi. La resistenza FPGA / ASIC è un punto controverso quando devi indovinare un input a 256 bit nella funzione hash.

Raccomandazioni

Genera le tue "password" con un RNG hardware o un CSPRNG e distruggere prontamente qualsiasi materiale seed che potrebbe essere utilizzato per ripristinare qualsiasi stato interno e quindi le password. Assicurati che siano lunghi 256 bit. Se il tuo sistema non supporta password non alfanumeriche o non ASCII, dopo generi i 256 bit, codificali in base-64 o base-26 o binari, se preferisci. (Ciò significa che le password effettive che invii saranno più lunghe di 32 byte, ma questo non aiuta molto l'entropia.)

Tratta queste password come chiavi crittografiche - idealmente, sarebbero memorizzate sull'hardware gettoni. Un gestore di password hardware funziona molto bene per questo scopo. Memorizza gli hash SHA-256 nel tuo sistema e verifica le password tramite l'hashing e il confronto. Dovresti rifiutare tutte le password tentate che non corrispondono al tuo criterio di generazione (un esempio potrebbe essere una password selezionata dall'utente < 256 bit), anche se gli hash corrispondono, e non dovresti permettere a nessuno di impostare una password che non proviene da CSRNG. Questo dovrebbe essere documentato. Ancora meglio è se aggiungi qualche byte di checksum oscuro alla fine delle password che generi che viene verificato dalla piattaforma prima che ti permetta di impostare la password. Questo dovrebbe dissuadere tutti, tranne le persone più esilarantemente incompetenti, dal mettere qualcosa di meno di una chiave crittografica sulla tua piattaforma.

Crittografia a chiave pubblica

Il tuo caso d'uso è un po 'strano. La maggior parte dei luoghi mantiene le password perché impostare una PKI e trattare con gli utenti finali è molto difficile, specialmente con cose come le chiavi pubbliche. Dato che sembri essere l'unico a inserire le password nel sistema, forse avrebbe più senso memorizzare le chiavi pubbliche Ed25519 o ECDSA sul sistema e scrivere lì il codice che implementa un protocollo di risposta alla sfida (uno semplice è firmare questo 256- valore in bit, ma fai attenzione a non riutilizzare queste chiavi, poiché qualcuno potrebbe indurti a firmare il tuo Bitcoin o una confessione criminale). Il dispositivo che si interfaccia con il tuo sistema qui e manterrebbe le chiavi private probabilmente ha una forte implementazione della crittografia a chiave pubblica e non avrebbe problemi ad autenticarsi. La tua implementazione "roll my own" della verifica della firma potrebbe essere la meno sicura al mondo in termini di attacchi side-channel (pensa di mettere il suo intero stato su un cartellone pubblicitario o sulla blockchain), purché fornisca la risposta corretta, e staresti perfettamente bene, poiché l'algoritmo di verifica semplicemente non ha accesso alle chiavi private.

Sono d'accordo con Mike e Royce nelle loro risposte e non sento il bisogno di ripetere ciò che hanno trattato bene. Tuttavia volevo indirizzare più direttamente questo tuo commento:

Informazioni aggiuntive: sarò l'unico a memorizzare le password su quel sistema, quindi posso 1) garantire che nessuna delle password sarà usato due volte e 2) assicurati che le password abbiano un'entropia molto alta.

Questa informazione è importante e non importante. Ecco perché:

Il caso dell'hashing delle password

È sempre importante ricordare il perché hash delle password e tutto bolle fino al riutilizzo della password. Il motivo per cui l'hashing delle password è così importante è perché quando il tuo sistema viene compromesso e le password vengono rubate, non è solo l'accesso al tuo sito che viene compromesso, ma l'accesso a tutti i siti in cui i tuoi utenti hanno riutilizzato la stessa email / password combinazione che (come sappiamo) accade spesso. L'hashing delle password riguarda la protezione degli utenti da se stessi. Se assolutamente tutti usassero password complesse e univoche su ogni sito, l'hashing della password sarebbe molto meno necessario. Avrebbe ancora un certo valore perché ci sono casi d'uso in cui un hacker potrebbe ottenere l'accesso in sola lettura a un dump del database, quindi le password con hash possono fornire una certa protezione contro gli aggressori che ottengono l'accesso effettivo al tuo sistema in. Tuttavia, se le persone lo usano forte e unico password ovunque, l'hashing delle password diventerebbe più una preoccupazione secondaria invece della necessità assolutamente critica che è oggi.

Quindi, se puoi garantire che ogni utente del tuo sistema utilizzerà sempre e solo password complesse e uniche (cioè password che non sono state utilizzate su altri siti), quindi penso che anche qualcosa di semplice come SHA2 sarebbe effettivamente una scelta perfettamente ragionevole, indipendentemente dal fatto che siano disponibili funzioni migliori.

MA: mutevoli esigenze aziendali

Tuttavia, ti incoraggio a ricontrollare le tue ipotesi (che password univoche forti saranno le uniche in assoluto nel tuo sistema). Ho visto le esigenze aziendali cambiare spesso in passato per fare affidamento su presupposti come quello in aree aziendali critiche (cosa che potrebbe non essere - ovviamente non so cosa fa). Il problema è che le esigenze aziendali cambiano. Forse sono solo io, ma nella mia esperienza le cose che dovevano essere temporanee o limitate a solo un paio di persone si trasformano inevitabilmente in applicazioni aziendali critiche utilizzate da tutti in azienda, e all'improvviso hai uno schema di password debole che protegge le attività critiche infrastruttura. Non sempre accadrà perché le persone stanno cercando di tagliare gli angoli, ma poiché dopo 12 mesi ti dimentichi di non aver utilizzato un ottimo hash della password, o te ne vai e poi il prossimo non lo fa Non esaminarlo, o sei sotto pressione per rispettare una scadenza e dimentichi, o, o, o ...

Nella mia esperienza le aziende finiscono per avere violazioni della sicurezza non perché la sicurezza sia difficile ma perché non capiscono la necessità di spendere tempo (ovvero denaro) in buone pratiche di sicurezza e tagliare gli angoli dove non dovrebbero. Certo, in questo momento adesso un ottimo schema di hashing delle password non ha importanza, ma puoi davvero garantire che non cambierà in futuro? Se non hai tempo per inserire il corretto hashing della password ora, puoi garantire che quando le esigenze cambiano e improvvisamente importa, avrai tempo per farlo subito?

Ovviamente alla fine della giornata ogni azienda ha bisogno di fare soldi e, a volte, "Per ora manteniamo le cose semplici per farlo uscire" è una risposta perfettamente ragionevole. Fai solo attenzione però, perché prendere questa decisione troppo spesso è il modo in cui le aziende finiscono con i sistemi pieni di falle di sicurezza. Come azienda devi trovare quell'equilibrio per te stesso. Il problema è che quando le aziende lesinano cronicamente sulla sicurezza, in ultima analisi, sono i loro clienti a soffrire di più.

Devo memorizzare le password su un sistema che non offre nessuno degli algoritmi consigliati per l'hashing delle password (ad esempio bcrypt, scrypt o PBKDF2). Sarebbe meglio utilizzare un algoritmo inadatto (ad esempio la famiglia SHA-1 o SHA-2) prima di utilizzarne nessuno?

La risposta rigorosa alla tua domanda è sì. Il motivo è che gli hash veloci non proteggeranno le password deboli, ma proteggeranno quelle molto forti, e questo è strettamente migliore del testo in chiaro.

Tuttavia, se hai SHA-1 o SHA-2 ci sono ci sono pochissime (se ce ne sono!) scuse per non usare PBKDF2. Sì, il consiglio comune è "non lanciare la tua crittografia", ma se hai SHA-1 o SHA-2 questo è già l'elemento fondamentale per PBKDF2 e per il caso dell'hashing della password che scrivi il tuo la propria implementazione di PBKDF2 difficilmente può essere peggiore di no . Ecco la RFC e la sezione pertinenti:

• https://tools.ietf.org/html/rfc2898#section-5.2

Quando dicono "funzione pseudocasuale" dovresti usare qualche variante HMAC (idealmente HMAC-SHA-512, ma qualunque di loro andrà bene). La tua libreria probabilmente ha già implementazioni HMAC, ma in caso contrario, l'hashing della password è di nuovo un caso in cui implementare la tua non può essere peggio di no.

Per rispondere alla tua domanda: sì, utilizza il miglior algoritmo a cui hai accesso. Se ne hai diverse, potresti combinarle (nota: la concatenazione di password, ad es. Sha1 (password) + md5sum (password), è più vulnerabile all'ipotesi, poiché un utente malintenzionato potrebbe scegliere quale hash vuole indovinare, ma le collisioni sono molto meno probabilmente, poiché entrambe le password devono corrispondere. Utilizza salt diversi e casuali per ciascuna password.

Dici che il tuo sistema "non offre nessuno degli algoritmi consigliati per l'hashing delle password". incoraggiarti a riesaminare questo presupposto.

Quasi tutti i linguaggi di programmazione moderni hanno implementazioni di hash sicuri. Non è necessario che siano implementati in una libreria preinstallata, ad esempio, se il tuo programma è scritto in C, dovresti essere in grado di trovare implementazioni di qualsiasi hash in C, come funzione autonoma. Anche piccoli processori come Arduino hanno bcrypt e PBKDF2, pronti all'uso. Il lavoro extra richiesto è minimo. potresti persino implementarlo da solo (ma fai molta attenzione e prova molto accuratamente!).

Non dubito che ci siano eccezioni, ma non ce ne sono molte.

SÌ, anche l'hash di bassa qualità è molto meglio che memorizzare le password in testo normale

Se capisco che aggiorni, qualcun altro eseguirà l'autenticazione (non correlato a tu e il tuo database) e utilizzerai il tuo database hash delle password solo per il rilevamento delle password duplicate? Il requisito per determinare l'entropia della password sarebbe basato sul testo in chiaro e non è correlato alla memorizzazione degli hash delle password, giusto?

Quindi puoi memorizzare nel tuo database hash solo una piccola parte del calcolato sha2 hash di salt + plaintext (ad esempio, memorizzando solo 8 byte bassi di 32 byte restituiti da sha256), che sarà sufficiente per rilevare i duplicati con nessun falso positivo nella vita reale, ma ancora non abbastanza per consentire all'autore dell'attacco di utilizzare le tabelle arcobaleno per indovinare la password originale in caso di furto del database.

(Dichiarazione di non responsabilità: se STAI effettuando l'autenticazione e non solo il rilevamento della password duplicata, eliminare parte dell'hash sarebbe ovviamente un'idea terribile!)

Sì , usare un hash debole è meglio di niente.

Penso che dovresti considerare anche il modo amministrativo. Se mantieni il database (ma non sei autorizzato a cambiare la struttura, chissà perché ...) non dovresti vedere le password in testo normale, anche se sei la persona più intera e non faresti alcun danno con quelle informazioni. Proprio come il proverbio: l'opportunità fa il ladro.

Sì, è decisamente meglio usare un semplice hash che niente (anche se vedendo come apparentemente implementa il sistema, non riesco a vedere cosa ti impedisce di fare le cose correttamente).

Tuttavia, data la tua modifica "Informazioni aggiuntive", uno potrebbe essere così audace da dire che non hai nemmeno bisogno del sale! Ciò non significa che sia un buon design e non lo consiglierei, ma se prendi sul serio le tue garanzie, un semplice hash sicuro di dimensioni ragionevoli è sufficiente, in senso stretto.

Perché uno fa una tale confusione sulla memorizzazione delle password in primo luogo? Di solito, le password sono a bassa entropia, e anche quando sono sottoposte ad hashing c'è una buona possibilità di indovinare una password, anche di più perché le funzioni hash sono molto veloci , banalmente parallelizzabili, e esistono tabelle arcobaleno che forniscono una scorciatoia economica . Quindi, anche se sono illeggibili dopo essere state sottoposte ad hashing, ciò non significa necessariamente che le password siano irrecuperabili.
In linea di principio, dato un tempo infinito, potresti recuperare ogni password su ogni sistema (o almeno una password che funzioni). Questa è solo una conseguenza del fatto che esiste un numero finito di output per una funzione hash. Quindi, in una ricerca quasi esaustiva, una sequenza di input deve necessariamente produrre un output che funzioni.
Fortunatamente gli aggressori non hanno tempo infinito, quindi il nostro compito è assicurarci che non abbiano una ragionevole possibilità di trovare una sequenza di input che funzioni entro un tempo finito e con una fornitura finita di energia.

Ora ... dici di essere l'unico utente e puoi garantire che le password sono casuali e ad alta entropia. Questo esclude la maggior parte delle preoccupazioni sull'ipotesi.

Data una dimensione del digest "ragionevole", ciò significa che la possibilità di trovare l'hash in una tabella arcobaleno è minima (zero, più o meno) e la possibilità di trovarlo con la forza bruta è ugualmente più o meno zero. Non c'è modo che qualcuno rompa la forza bruta di SHA-256, figuriamoci SHA-512. Questa idea semplicemente non è compatibile con la nostra comprensione di come funziona la fisica.
Se il digest è abbastanza grande e le password sono garantite (come dichiari) come uniche, casuali, ad alta entropia ... in realtà sei buono solo per eseguire l'hashing una volta.

Ora, naturalmente, normalmente un sistema dovrebbe funzionare in modo affidabile anche se non puoi fornire quella garanzia (o qualsiasi per questo motivo). Quindi, non è il design migliore.

Sì, dovresti stare bene. SHA1 e 2 sono ancora abbastanza potenti per la memorizzazione di hash di password ad alta entropia e forniranno una protezione adeguata dalla forzatura bruta. SHA2 fornisce una protezione migliore rispetto a SHA1. Le vulnerabilità in SHA2 non sono rilevanti per questo scenario poiché riguardano la creazione di collisioni in cui il testo in chiaro iniziale è già noto.

Per andare d'accordo con le eccellenti risposte di cui sopra, voglio dare una risposta complementare ma contraria:

No . Usare un hash debole è peggio che non usare affatto un hash.

Un hash debole ti dà l'illusione della sicurezza.

Mentre tu e i tuoi manager potrebbe capire al momento che l'hash non offre una vera sicurezza, un manager o uno sviluppatore in fondo può pensare che l'hash sia sicuro. Queste persone possono decidere di memorizzare informazioni aggiuntive utilizzando l'hash in questione.

C'è anche il rischio che la direzione non si limiti a capire che l'hash non è sicuro per cominciare. Quando devono decidere di investire nello sviluppo della sicurezza, possono decidere che "il sistema attuale è abbastanza buono" perché è già sottoposto a hashing e l'hashing è considerato una best practice.