Domanda:
È una cattiva pratica aggiungere il prefisso al mio hash con l'algoritmo utilizzato?
Mathias Lykkegaard Lorenzen
2018-11-08 19:25:07 UTC
view on stackexchange narkive permalink

Diciamo che ho un database con un gruppo di utenti al suo interno. Questo database utente avrebbe in genere una password con hash per utente. Sarebbe una cattiva pratica anteporre a questo hash l'algoritmo di hashing utilizzato?

Ad esempio, invece dell'hash aaf4c61ddcc5e8a2dabede0f3b482cd9aea9434d , memorizzo sha1_aaf4c61ddcc5e8a2dabede0f3b9448cd , poiché il metodo per creare l'hash è SHA1.

Ho notato che Argon2 lo fa, e in realtà penso che sia abbastanza conveniente, perché rende più facile migrare parzialmente a nuovi algoritmi di hashing per i nuovi utenti nel tempo.

Non uso SHA1 nel mio codice di produzione per le password. SHA1 è stato scelto in modo casuale. Questa domanda non riguarda l'uso del metodo di hashing.

I commenti non sono per discussioni estese;questa conversazione è stata [spostata in chat] (https://chat.stackexchange.com/rooms/85699/discussion-on-question-by-mathias-lykkegaard-lorenzen-is-it-bad-practice-to-pref).
Cinque risposte:
schroeder
2018-11-08 19:28:19 UTC
view on stackexchange narkive permalink

Molti diversi sistemi di hashing delle password lo fanno. Il tipo di meccanismo di hashing utilizzato non dovrebbe essere (e non dovrebbe essere necessario) un segreto. Il principio di Kerckhoffs dice:

Un sistema crittografico dovrebbe essere sicuro anche se tutto ciò che riguarda il sistema, tranne la chiave, è di dominio pubblico.

Quindi, se il tuo sistema è adeguatamente protetto, non dovrebbe importare se il meccanismo di hash è esposto.

Perché "non dovrebbe essere"?Non dovrebbe _bisogno_ di essere segreto è il principio di Kerckhoffs, ma fintanto che non ti fa compromettere la sicurezza delle chiavi non può certamente causare danni se anche l'algoritmo hash è segreto.
@leftaroundabout che riguarda Kerckhoffs.Dal punto di vista operativo e politico, classificare l'algoritmo di hashing come segreto è un problema.Tenta di fornire sicurezza attraverso l'oscurità e introduce costi di controllo che superano i benefici.Per non parlare del pratico caso d'uso fornito da Toby Speight.Non si tratta di anteporre il tipo alo, si tratta della classificazione dei dati sul tipo di algo.
_Classificarlo_ come segreto non è necessario perché è segreto.Può essere segreto incidentalmente, per motivi di prestazioni.
Differenza tra renderlo segreto e, per inciso, non rivelarlo.In questo caso, la domanda riguarda la classificazione di tali dati, non la mancata divulgazione (sebbene il contesto riguardi la divulgazione).
Avevo l'impressione che l'aggiunta di "sicurezza tramite oscurità" fosse ancora una buona cosa.I sistemi * dovrebbero * essere sicuri, anche se si conoscono tutti i dettagli del sistema, ma l'aggiunta di oscurità aggiunge sicurezza (per rallentare gli aggressori, per nascondere i sistemi quando vengono trovati bug di 0 giorni, ecc.).È così giusto?
@NathanMerrill Direi che dovrebbe essere preso caso per caso.In questo caso, penso che il vantaggio di avere l'algoritmo memorizzato con l'hash supera in modo significativo il minimo vantaggio di sicurezza che si otterrebbe oscurandolo.
Dovrò essere d'accordo con @leftaroundabout.Questa interpretazione di Kerckhoff è, a mio parere, similmente difettosa come l'interpretazione comune del rasoio di Occam che dice "la soluzione più semplice è sempre quella giusta".Rendere un dettaglio di implementazione un segreto (o almeno un po 'oscuro) non è male fintanto che non ci si affida come misura di sicurezza.Tuttavia, rende la vita di un attaccante inesperto un po 'più difficile.Molte aziende hanno la loro "salsa segreta", ovvero i segreti commerciali protetti con mezzi legali (che funzioneranno anche se il segreto è noto) ma _continuano_ mantengono i loro segreti _secret_.
@Damon, quello che volevo dire era che non va bene raggruppare i dettagli di implementazione in testo in chiaro con una cifra solo per "aderire al principio di Kerckhoffs".Questo non ti compra nulla, a meno che non abbia vantaggi indipendenti (come facilitare la migrazione a un altro hash, ma per questo, anteporre il nome dell'hash in ASCII non è l'unica opzione e probabilmente è piuttosto hacky).Pubblicare deliberatamente i dettagli di implementazione è solo uno _vantaggio_ se è fatto in modo tale da fornire una revisione tra pari (libreria open source ecc.).Se niente di tutto ciò si applica, mantenerlo semplice e omettere il nome dell'algoritmo.
Il principio di @NathanMerrill Kerkhoff viene utilizzato per consentire sistemi di indurimento.Se tutto tranne la chiave è aperto, può essere esaminato in modo completo.Se parti del sistema non sono aperte, chiunque cerchi di verificarne la sicurezza deve decodificare quelle parti prima di poterle valutare correttamente.
@leftaroundabout: Esattamente, è quello che sto dicendo.Pubblicare un segreto per amore di "because Kerckhoff!"è un'interpretazione errata di quel principio (a mio parere).
@Deduplicator è vero: vuoi che sia oscuro per gli aggressori, ma non oscuro per i valutatori.Ci sono sicuramente scenari in cui ciò non è possibile.
Anders
2018-11-08 19:41:49 UTC
view on stackexchange narkive permalink

Sono d'accordo con schroeder sul fatto che questo sia OK. Anche senza un prefisso, un utente malintenzionato può probabilmente capire quale algoritmo stai utilizzando. E comunque, è la forza dell'algoritmo di hashing che protegge le password, non la segretezza dell'algoritmo.

Nota che molti algoritmi e librerie di hashing lo fanno già per te. Incorporano tutte le informazioni rilevanti - algoritmo, fattori di costo, sale, l'hash effettivo - in una stringa serializzata. Vedi ad esempio la funzione Modular Crypt Format o la funzione password_hash di PHP. Quindi non inventare il tuo schema. Se stai usando una libreria di hashing discendente, ne hai già una.

Non usare SHA1 per hash delle password, però. Non va bene.

Sì, ho usato SHA1 perché ho l'hash di "ciao" era troppo lungo per un esempio in SHA512.
@MathiasLykkegaardLorenzen Non usare neanche SHA512, a meno che non sia solo un componente in uno schema più grande con più iterazioni.Ma ovviamente, per esempio, va bene tutto!:-)
@MathiasLykkegaardLorenzen E non usare nemmeno più iterazioni!Usa un costrutto collaudato come PBKDF2, che utilizza HMAC (non solo iterazioni hash non elaborate).
SHA512 è considerato insicuro?Non lo sapevo in questo momento.Puoi fare riferimento a un articolo che spiega il motivo?
Non è insicuro per ciò per cui è stato progettato (cioè hashing dei dati), ma è stato progettato per essere * veloce *.Vuoi che la funzione di hash della password sia lenta per evitare tentativi di forza bruta.
Ma anche se è veloce, importa se la quantità di tentativi che sarebbero necessari (dato che si aggiunge sale e pepe) è ancora follemente alta?
Sì, è ancora importante.Le funzioni di hash non sono pensate per l'archiviazione delle password a causa della loro velocità.Con una singola istanza p3.16xlarge su Amazon, puoi eseguire 17,28 miliardi di tentativi al secondo su SHA512.Ciò significa che puoi decifrare qualsiasi password di 8 caratteri composta da lettere e numeri in soli 151,17 secondi.Le funzioni di derivazione chiave sono realizzate per memorizzare le password poiché sono lente.Con bcrypt su workfactor 12 puoi fare solo 424200 ipotesi al secondo.Ciò richiederebbe 34,8 giorni per password.Inoltre bcrypt e argon2 hanno sali incorporati, quindi non devi preoccuparti di saltare le password.
Toby Speight
2018-11-08 21:59:44 UTC
view on stackexchange narkive permalink

No, non è una cattiva pratica e probabilmente dovresti conservare queste informazioni.

Come osservi, questo ti consente di cambiare algoritmo per nuove password ogni volta che vuoi, senza invalidare le password esistenti di tutti gli utenti (farlo tende a renderti impopolare, per qualche motivo).

C'è un argomento secondo cui questo consente a un utente malintenzionato di cercare le password più vecchie e deboli per attaccare per prime, ma tu non hanno ridotto la loro sicurezza (assumendo il principio di Kerckhoff, che l'algoritmo stesso non deve essere un segreto).

Se è possibile memorizzare una combinazione di algoritmi e sali, non è necessario mantenere password più deboli una volta disponibili algoritmi più potenti.Se la voce corrente dice che inserire la password attraverso weakAlgorithm con salt1 produce X, calcola semplicemente Y inserendo X attraverso un StrongAlgorithm con salt2, quindi cambia la voce per dire che inserendo la password attraverso weakAlgorithm con salt1, e quindi inserendo il risultato di *che * attraverso un algoritmo più forte con salt2, produrrà Y. Non è necessario attendere che l'utente effettui il login.
leo v
2018-11-09 01:27:51 UTC
view on stackexchange narkive permalink

È buona norma memorizzare l'algoritmo di hashing, ma le funzioni di hashing delle password appropriate come Argon2 e PBKDF2 si occupano già di questo. Tuttavia, è una cattiva pratica utilizzare SHA1 o SHA256 da soli per l'hashing delle password perché sono una quantità fissa (e relativamente piccola) di lavoro da crackare utilizzando attacchi di dizionario e forza bruta. Quelle password dovrebbero essere migrate a una funzione di hashing sicura modificando nuovamente la password al successivo accesso. Vedi https://crypto.stackexchange.com/a/45405 per i dettagli.

Nicolas Marshall
2018-11-10 00:11:22 UTC
view on stackexchange narkive permalink

Non è una cattiva pratica, in realtà è una cosa comune da fare. Infatti, se apri il file / etc / shadow su una macchina Linux vedrai la tua password con hash preceduta da $ x $ salt $ dove x è un numero che indica quale algoritmo di hashing è stato utilizzato.

Ora alcune cose da considerare:

  • non utilizzare SHA1 direttamente come algoritmo di hashing. Usa invece bcrypt, scrypt o argon2 (che hai menzionato ma non può essere ripetuto troppo). Questi usano un semplice algoritmo di hashing come SHA1 come base, ma lo eseguono in un modo speciale che lo rende resistente agli attacchi.
  • per motivi pratici, poiché stai usando un database e non un file, potresti voler memorizzare il metodo di hashing e il sale in righe separate. Tuttavia puoi anche scegliere di memorizzare la stringa che inizia con $ x $ salt $ nel tuo database e analizzare il metodo salt e hashing da quella stringa nel momento in cui controlli la password. Probabilmente è abbastanza veloce da non fare alcuna differenza significativa. E in entrambi i casi la sicurezza del tuo sistema sarà la stessa.
L'OP afferma nei commenti che SHA-1 è stato utilizzato solo come esempio e non viene utilizzato nella produzione
È necessario utilizzare più di "eseguire più volte", è necessario disporre di un utilizzo della CPU o ~ 100 ms e un salt casuale.
@schroeder Non ero così sicuro leggendo la domanda.
@zaph è assolutamente d'accordo, ma non volevo entrare nello specifico.Ho modificato la mia risposta per renderla meno ambigua


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