Domanda:
È meglio usare un algoritmo di hashing inadatto invece di nessuno?
JFB
2018-11-19 21:16:42 UTC
view on stackexchange narkive permalink

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 (es. Famiglia SHA-1 o SHA-2) prima di non utilizzarne nessuno?


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

Quindi stai generando le password e gestendole?Non sono password utente?Il meccanismo di autenticazione esiste già o è una nuova funzionalità?
Hai la capacità di * allungare * l'algoritmo - per applicare lo stesso algoritmo molte volte?Se è così, fallo come minimo.
Sembra che tu abbia un alto grado di controllo sulle password da memorizzare .. Non hai un livello simile di controllo su * come * vengono archiviate?Non puoi scegliere di trovare qualcosa di meglio?
Non ho capito bene.Se stai aggiungendo il codice di autenticazione, come fai a non avere la possibilità di inserire una libreria che implementa i protocolli di hashing più recenti?Mi chiedo anche se stai facendo qualcosa come l'aggiunta di un utente amministratore a un dispositivo che poi è stato distribuito?Penso che questa domanda manchi di dettagli sufficienti per essere veramente risolvibile.Fornisci maggiori dettagli su ciò che stai implementando che conterrà la password (un'interfaccia web, un dispositivo IoT, qualunque cosa) e perché devi bloccare qualcosa.(Se stai distribuendo un dispositivo, non ha senso nemmeno avere la password.)
No, questo presenta un falso senso di sicurezza, il che è anche peggio, fortunatamente ci sono servizi di crittografia con cui puoi interfacciarti, eccone uno: https://docs.aws.amazon.com/kms/latest/developerguide/overview.html
Se davvero non puoi usare nessuno degli algoritmi che dovresti usare (bcrypt, scrypt, et al), allora almeno usa il salt e il key stretching con un numero elevato (decine di migliaia) di iterazioni.Ma seriamente, dovresti trovare un modo per utilizzare un algoritmo appropriato.SHA-1 è stato teoricamente rotto a causa di una remota possibilità di collisioni.Probabilmente non è rotto in pratica poiché le collisioni sono estremamente improbabili.Tuttavia, se hai intenzione di fare qualcosa di simile, usa invece SHA-256 o SHA-512.
@RandomUs1r Puoi utilizzare servizi di crittografia online come questo solo se hai la certezza che il tuo sistema sarà online ogni volta che viene utilizzato.Non è stato specificato, ma potrebbe non essere garantito.
Prendi in considerazione l'utilizzo di un contenitore Docker leggero per installare tutte le librerie necessarie, quindi utilizza il contenitore per l'hash.
Perché dici che le pw sono uniche?Non dovrebbe essere affatto rilevante.
Inoltre, garantire l'unicità della password è in qualche modo un difetto piuttosto che una sicurezza (se non del tutto): dovrai indicare a un utente che tenta di riutilizzare una password esistente che non può essere utilizzata, dando quindi loro l'indicazione che questa password esistegià nel tuo database (o almeno è facile arrivare a questa conclusione)
Progettiamo software per adattarsi a determinati vincoli.Hai due vincoli in competizione: sicurezza per i tuoi utenti e ambiente tecnologico che non può eseguire l'hashing delle password.Soluzione: cambia i tuoi vincoli.Cosa apprezzi di più, mantenendo le password degli utenti al sicuro o attenendoti a una tecnologia particolare?
Le "informazioni aggiuntive" sollevano ulteriori domande.La memorizzazione degli hash non "garantisce che le password abbiano un'entropia elevata" e se il sistema impedisce a utenti diversi di avere la stessa password ("nessuna delle password verrà utilizzata due volte") è un'idea terribile.Hai fornito a un utente malintenzionato un oracolo che può dirgli se una password è già in uso nel sistema.Non farlo!
Per mettere il mio commento sopra in un altro modo: non hai specificato il tuo modello di minaccia.È da qualche parte tra estremamente difficile e impossibile valutare una misura di sicurezza senza capire da quale minaccia dovrebbe difendersi.I tuoi dati non sono in linea con i casi standard per quando hai bisogno di account per noi per fare ipotesi plausibili sulle minacce che hai in mente.Il risultato è che si ottengono risposte dal presupposto che il tipico "utente finale crea un account e dispone di alcune risorse che devono essere protette".
@LaurentS.Se la password non può essere utilizzata, non c'è rischio di conoscerla.Probabilmente sapendo che questo riduce un po 'lo spazio di attacco, ma poiché hai già dovuto lavorare per determinarlo, non sembra esserci alcun guadagno netto per l'attaccante.
@LaurentS: non solo hai dato all'aggressore un oracolo, assicurando l'unicità della password essenzialmente stai dicendo all'aggressore che non stai memorizzando correttamente la tua password.Con un corretto hashing della password, dovrebbe essere impossibile stabilire se due account utilizzano la stessa password.È quasi un invito a sondare di più.
@LieRyan: infatti.Questo è probabilmente il motivo per cui in realtà non ho mai incontrato una caratteristica del genere tra i tanti torti che ho visto finora.
È meglio chiudere la porta di casa con del nastro adesivo invece di lasciarla aperta quando esci (se non hai la serratura)?
Dodici risposte:
#1
+117
dFrancisco
2018-11-19 21:22:01 UTC
view on stackexchange narkive permalink

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.

Ho aggiornato la mia domanda con informazioni aggiuntive, aiuta?
@JFB Non eccessivamente.Le informazioni extra sono buone e significa che il danno causato dalla compromissione di password con hash debole, forti e mai riutilizzate è ovviamente meno dannoso rispetto alla compromissione delle password degli utenti ordinari autentici, ma non aiuta a focalizzare troppo la mia risposta.
E se il mio capo desidera che il sistema sia in grado di ricordare effettivamente e non solo reimpostare le password?Lo vogliono così tanto che sono disposti a sacrificare la sicurezza per questo.Come rispondereste a tale richiesta?
@Gherman come con qualsiasi cosa, fai un'analisi costi / benefici e lasci decidere al decisore e al proprietario del rischio.
@dFrancisco che rifiuta di aggiungere una nuova funzionalità va bene se sei il proprietario del sistema, ma non hai basi per rifiutare se sei l'amministratore o lo sviluppatore.*** Consigliare ed educare *** è il tuo ruolo di professionista della sicurezza.
Sarebbe meglio riformulare il tuo rifiuto in * termini commerciali * piuttosto che semplicemente con la vaga "sicurezza".Ad esempio, "Memorizzeremmo consapevolmente i dati sensibili in un modo che renda più facile ottenerli da parte di un utente malintenzionato. Potrebbe trattarsi di una violazione del GDRP / HIPPA / qualsiasi standard pertinente-the-company-might-get-inguai per rompere e aprirci a conseguenze legali ".Ma questa * è * la linea di condotta corretta per la gestione utente generica.
@Wildcard cerchiamo di non impazzire con i salti di logica, i "pendii scivolosi" e l'assurdo.C'è un ampio campo di gioco tra "non rifiutare" e "aggiungere la funzione".Si prega di prendere ulteriori commenti per chattare.
Mentre un hashish debole è leggermente meglio di niente, un hash debole * salato * è significativamente meglio di niente.Niente nella domanda o in questa risposta si riferisce alla salatura, quindi è probabilmente una buona idea farne una menzione specifica.
"qualcosa è meglio di niente" è vero solo se qualcosa è MEGLIO di niente (e non dà l'impressione che sia più efficace) - per esempio MD5 non salato o ROT13 o altro.
@Joe Ti darò ROT13, ma MD5 non salato * è * meglio di niente, e MD5 salato è notevolmente migliore di SHA3 non salato.
@MartinBonner Se è davvero meglio, è così banalmente "migliore" che possiamo (e dobbiamo, per evitare di fuorviare le persone) trascurare la differenza.
#2
+48
Mike Ounsworth
2018-11-19 21:28:28 UTC
view on stackexchange narkive permalink

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).

Suggerirei di includere Argon2 nel tuo elenco, poiché è attualmente l'algoritmo preferito quando GPU o cracking FPGA / ASIC sono nel tuo modello di minaccia (come dovrebbero essere).
+1.Nota che questo dipende in realtà da quanto tempo la tua base di utenti è disposta ad aspettare l'autenticazione (e quanto carico possono sopportare i tuoi sistemi di autenticazione in parallelo).Al livello inferiore a 100 ms, bcrypt è in realtà più resistente alla forza bruta.Solo sopra ~ 1s / auth Argon2 diventa superiore.Rif: https://twitter.com/Sc00bzT/status/1063895918246862848, https://twitter.com/Sc00bzT/status/1041875128311840768
É davvero?Mi dici che archivi in modo sicuro i miei dati, ti do dati sensibili da archiviare, quindi perdi i dati perché non sono effettivamente sicuri, non sarebbe meglio essere in anticipo e dichiarare che non stai archiviando in modo sicuro i dati nelprimo posto?... idealisticamente parlando
SHA-1 non è stato ancora violato contro preimage.Terrà.
@RandomUs1r Cosa intendi per "archiviazione non sicura dei dati"?PBKDF2, sebbene un po 'vecchio, è ancora considerato sicuro se si utilizzano 10.000 iterazioni di SHA-1 o SHA-2 e sali univoci per utente.Se hai a disposizione una primitiva SHA-2, puoi creare PBKDF2 (o qualcosa che è funzionalmente equivalente).Per favore conferma la tua affermazione che questa è solo un'illusione di sicurezza.
"L'utilizzo di qualsiasi hash crittografico darà i vantaggi di 2."Suppongo che dovrebbe essere ovvio, ma potrebbe valere la pena aggiungere "salato" dopo "qualsiasi".
Non ho familiarità con i dettagli dell'implementazione di PBKDF2.Ma supponendo che tu abbia una solida implementazione dell'algoritmo di hashing sottostante come SHA-1 o SHA-2, è accettabile implementare PBKDF2 da solo se gli sviluppatori non sono esperti di crittografia?
@JFB Penso di sì, ma non lo darei al nuovo assunto.Guardare le specifiche PBKDF2 o un'implementazione open source e applicare una quantità media di attenzione ai dettagli farebbe il trucco.In altre parole: mi fiderei di me stesso per implementare qualcosa di tipo PBKDF2 in un giorno o due e utilizzarlo in prod.In nessun caso mi fiderei di implementare SHA-2 in meno di un mese.
#3
+30
Royce Williams
2018-11-19 21:45:45 UTC
view on stackexchange narkive permalink

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).]

Ho aggiornato la mia domanda con informazioni aggiuntive che affrontano il tuo punto di essere in grado di proteggere almeno password complesse e univoche
* Riutilizzo della password * è quando gli utenti scelgono di utilizzare la stessa password su più siti (Facebook, la loro banca, ecc.) ... non quando due utenti utilizzano la stessa password sullo * stesso * sito.
Sono d'accordo, ma con l'avvertenza aggiunta che NON dovresti usare SHA-1 per produrre un riassunto di dati sensibili (come le password) senza usare salt casuale per indirizzare il riutilizzo della password, oltre allo stretching dei tasti.
Upvote per `` anche un hash debole proteggerà una password complessa ''
#4
+16
John Adams
2018-11-20 10:27:03 UTC
view on stackexchange narkive permalink

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.

Io ... um ... La maggior parte di questa risposta sembra riguardare ** completamente ** argomenti di crittografia non correlati e / o altamente fuorvianti.Il resto è disconnesso dal modo in cui funzionano effettivamente le tecniche di memorizzazione delle password.Salatura e iterazioni sono al 100% il modo in cui le password vengono archiviate in modo sicuro.Inoltre, raccomandare a qualcuno di usare SHA-2 puro è * molto * pessimo consiglio;il mio rig 6x 1080 può indovinare 18,7 * miliardi di password al secondo * di SHA-2, ma solo 95.000 al secondo di bcrypt costa 5 (e bcrypt costa 12 o superiore è l'attuale obiettivo moderno)
@RoyceWilliams Non sono un professionista della sicurezza, ma se capisco correttamente OP, stanno sostenendo che gli utenti inseriscano non meno di 256 bit di entropia per le password.Anche con i tuoi 18,7 miliardi di tentativi al secondo, se i miei calcoli matematici sul tovagliolo sono corretti (`(2 ^ 256) / 18.700.000.000 / 60/60/24 / 365`) allora avresti ancora bisogno di 1.963 * e + 59anni per provare tutte le combinazioni, che penso si qualificherebbero come "computazionalmente non fattibili" anche se si presume che l'hardware altamente ottimizzato sarebbe 100.000 volte più efficiente.
In altre parole, a un professionista non della sicurezza come me, sembrerebbe che chi risponde abbia ragione in quanto ogni algoritmo di hashing resistente alla preimage potrebbe essere considerato sicuro se si possono garantire password di entropia a 256 bit non riutilizzate.
@RoyceWilliams sì, penso che il problema principale sia che il suggerimento generale che JohnAdams sta facendo potrebbe essere un po 'più chiaro.Sembra che stia suggerendo di non utilizzare affatto le password, ma piuttosto di utilizzare l'autenticazione basata su chiave.In quel caso, infatti, né iterazioni né salatura importa.
Per dirla semplicemente, le password molto lunghe e generate in modo sicuro sono essenzialmente ciò che sono le chiavi crittografiche.
@RoyceWilliams Sembri fraintendere il succo della risposta.Se le tue password hanno abbastanza entropia, allora un KDF non è necessario.I KDF vengono utilizzati perché la maggior parte delle password sono a bassa entropia.Quando le tue password raggiungono livelli di entropia paragonabili a quelli delle chiavi crittografiche, non importa davvero come vengono hash, a patto che l'hash abbia una resistenza preimage.
Tutto ciò sembra fantastico .. * se * hai il lusso drammaticamente raro di costringere tutti gli utenti a utilizzare solo password generate automaticamente.Non appena agli utenti è consentito scegliere le proprie password, tutto il ragionamento precedente è irrilevante.E fare un'affermazione generale iniziale che un hash veloce è buono come un hash lento invia esattamente il messaggio opposto a quello che vogliamo che gli amministratori di sistema e gli sviluppatori sappiano: che * gli hash forti proteggono le password deboli e la maggior parte degli utenti sceglie password deboli *.
Nota anche che ho dato la mia risposta prima che l'OP ci dicesse che sono l'unico utente del sistema.Ho aggiornato di conseguenza la mia domanda e suggerisco di modificare tutte le altre risposte per rendere * molto * chiaro in primo piano il motivo per cui questo è un caso d'angolo insolito - altrimenti, stanno dando consigli * molto * negativi per il 99,9% dicasi ... e molti utenti SE scorreranno la domanda, andranno alle risposte più alte e giungeranno alla conclusione esattamente opposta a quella di cui quasi tutti hanno bisogno.
Il mio problema con questa risposta è che può essere riassunto in due frasi: "Non usare password, usa le chiavi. Le chiavi non possono essere forzate, quindi se usi le chiavi non devi preoccuparti tanto dell'hashing."Questo è sicuramente un buon consiglio di sicurezza ed è vero al 100% (le chiavi sono più sicure ed effettivamente non possono essere forzate).Tuttavia, è molto improbabile che sia un consiglio utile per l'OP, poiché anche gli accessi basati su chiave richiedono un po 'di tempo per essere configurati in un modo conveniente per l'utente.
In breve, l'OP sta cercando di mettere in atto la sicurezza di base con un minimo di problemi e tu stai proponendo una risposta che offre una sicurezza sorprendente con una grande quantità di problemi.C'è spesso un compromesso tra usabilità e sicurezza.L'OP sta chiaramente cercando di favorire il lato dell'usabilità di quello spettro e tu stai proponendo una soluzione che offre un'elevata sicurezza al costo di una minore usabilità.In poche parole: se non ha tempo per impostare un algoritmo di hashing adeguato, dubito che abbia tempo per trovare un RNG basato su hardware.
#5
+4
Conor Mancone
2018-11-19 23:49:13 UTC
view on stackexchange narkive permalink

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ù.

+1 per "cose che dovevano essere temporanee o limitate a un paio di persone inevitabilmente si trasformano in applicazioni aziendali critiche"
#6
+2
Luis Casillas
2018-11-20 07:15:06 UTC
view on stackexchange narkive permalink

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:

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.

#7
+1
AMADANON Inc.
2018-11-20 03:25:05 UTC
view on stackexchange narkive permalink

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.

#8
  0
Matija Nalis
2018-11-20 03:07:26 UTC
view on stackexchange narkive permalink

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!)

#9
  0
Lithilion
2018-11-20 14:19:29 UTC
view on stackexchange narkive permalink

, 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.

#10
  0
Damon
2018-11-20 15:05:32 UTC
view on stackexchange narkive permalink

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.

#11
  0
Jake
2018-11-21 01:49:36 UTC
view on stackexchange narkive permalink

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.

Questo è semplicemente sbagliato.https://www.pcworld.com/article/3173791/security/stop-using-sha1-it-s-now-completely-unsafe.html https://dusted.codes/sha-256-is-not-a-secure-password-hashing-algorithm
Inoltre ... https://crypto.stackexchange.com/a/35642
È giusto.L'articolo di PC-World parla della generazione di una collisione da un testo in chiaro noto.Questa è una cattiva notizia per alcuni tipi di certificati o per l'integrità dei file, ma va bene per le password.Il secondo dice solo che le password deboli non salate sono facili da decifrare.Questo è vero per tutti gli algoritmi di hashing e irrilevante in questo scenario.Il collegamento SE dice la stessa cosa che ho fatto.Assicurati solo di implementare correttamente il resto del sistema e di utilizzare password complesse.
#12
  0
Gregory Currie
2018-11-23 09:20:32 UTC
view on stackexchange narkive permalink

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.



Questa domanda e risposta è stata tradotta automaticamente dalla lingua inglese. Il contenuto originale è disponibile su stackexchange, che ringraziamo per la licenza cc by-sa 4.0 con cui è distribuito.
Loading...