Quando le password di hashing, è giusto memorizzare l'algoritmo utilizzato proprio lì nel database?

Question

Quando le password di hashing, è giusto memorizzare l'algoritmo utilizzato proprio lì nel database?

#1 da (12 voti)
#2 da (2 voti)
#3 da (0 voti)
#4 da (0 voti)
#5 da (0 voti)

5

Poiché la password di hashing è diventata di recente un argomento scottante, è naturale aspettarsi che le cose cambino e supponiamo che in qualche momento lungo la strada potresti voler sostituire / modificare l'algoritmo usato nel tuo sistema. Ciò comporterebbe naturalmente diversi tipi di hash memorizzati per vecchi e nuovi utenti.

Mi chiedo se sarebbe accettabile se avessi archiviato l'algoritmo utilizzato nel database anteposto a ciascun hash? Qualcosa di simile a come appare l'output di bcrypt: $2a$... (la versione dell'algoritmo). Cosa succede se lo memorizzo per nome come sha1$f6238eb6ca... ?

Rende le cose notevolmente peggiori per esplicitare esplicitamente l'algoritmo usato? Sto pensando, anche se l'hacker conosce l'algoritmo esatto (di pochissimi) è più o meno lo stesso ordine di lavoro per craccarlo, x1 o x5 non è un grosso problema, lo stesso O (sforzo). Ma mi rende le cose più semplici da gestire.

Cosa ne pensano gli esperti?

Aggiornamento. Stavo pensando ad un'altra opzione come il riferimento a un particolare algoritmo di codici come alg1, alg2 e scrivere le spiegazioni di quei riferimenti da qualche altra parte, nell'applicazione, forse, per mantenere queste informazioni a portata di mano. Se la mia idea originale dovesse risultare negativa, questo approccio la correggerebbe?

passwords hash databases

posta anon_user 21.01.2013 - 01:54

fonte

5 risposte

Leggi altre domande sui tag passwords hash databases

Che tipo di attacchi risultano in un utente malintenzionato che è in grado di divulgare il database di un sito? Quali sono le tecniche di tracciamento web maggiormente utilizzate e conosciute o meno conosciute? [chiuso]

score 12 · Answer 1

Certo che va bene. Questa è una semplice applicazione del principio di Kerckhoffs : la segretezza non si trova nell'algoritmo, ma nella chiave o nella password. Per cominciare, chiunque abbia accesso alla tua implementazione, o alla sua documentazione, o chissà che cosa è supportato dalle librerie con cui è costruita l'applicazione, sa quale algoritmo (i) la tua applicazione potrebbe utilizzare. Al massimo, l'attaccante dovrebbe provare una piccola lista. E se ci sono diverse possibilità, la tua applicazione dovrebbe anche provare quell'elenco, rendendo l'autenticazione più lenta senza una buona ragione (aumenti il tuo carico di lavoro dello stesso importo di quello dell'attaccante).

Come hai notato, è prassi comune anteporre l'identificazione dell'algoritmo al sale e all'hash. Certo, la pratica comune non è sempre ragionevole, ma eccola qui. Bcrypt utilizza codici numerici ereditati dalla pratica Unix. Puoi utilizzare il tuo schema di denominazione, se preferisci, anche se come al solito dovresti attenersi a ciò che fornisce la tua libreria, a meno che tu non abbia una buona ragione per fare le tue cose.

score 2 · Answer 2

Questo non fa peggiorare le cose, e in effetti molte soluzioni di storage hashing fanno esattamente questo (simile all'esempio di output di bcrypt) in modo che il SO (o l'applicazione) sappia quale algoritmo di hashing usare per comparare allo stored hash.

La sicurezza non dipende dal mantenere l'algoritmo segreto in alcun modo - si basa su un algoritmo sufficientemente robusto che le possibilità di due password che recapitano lo stesso hash in circostanze normali sono incredibilmente basse e lo sforzo richiesto per confrontare la forza bruta gli hash generati sono il più alti possibile.

score 0 · Answer 3

Solitamente la lunghezza dell'output dell'hash è sufficiente per rinunciare a quel segreto:

MD5: 128 bit
SHA1: 160 bit
SHA256: 256-bit
SHA512 : 512-bit

Tentare di mantenere segreto il tuo algoritmo è una battaglia persa. Desideri sicurezza attraverso la segretezza , non sicurezza attraverso l'oscurità .

score 0 · Answer 4

Come altri hanno già spiegato, cercare di mantenere segreto l'algoritmo non è una buona idea. Tuttavia, se si desidera una protezione aggiuntiva dagli attacchi che compromettono il database ma non il codice eseguibile, è possibile memorizzare un valore "pepe" segreto e / o un algoritmo nel codice, in modo che l'utente malintenzionato debba capire cosa esattamente si fa con i dati prima di averlo cancellato. Cercare di mantenere il segreto di altimetria in questo caso offre ancora poca sicurezza (dato che non è così difficile da capire), ma mantenere la chiave segreta complicherà considerevolmente qualsiasi attacco.

Vedi Come fare in modo sicuro le password di hash? per ulteriori informazioni sull'argomento .

score 0 · Answer 5

Prima di tutto il requisito per gli standard di crittografia moderni era che l'aver saputo un algoritmo da parte degli attaccanti non diminuiva la protezione del sistema se tutte le regole, in particolare, per le chiavi, sono state fatte.

Pensa che molti degli algoritmi sono open source, in effetti, nessuno in Linux. Quindi il concetto base di sicurezza qui è la forza delle chiavi utilizzate.