Password Hashing Flaw

Question

Password Hashing Flaw

#1 da (3 voti)
#2 da (2 voti)
#3 da (-1 voti)

3

Dichiarazione di non responsabilità: sono a conoscenza dei pericoli legati al rotolamento della propria autenticazione, questo esempio è destinato a essere utilizzato in una demo per vari metodi di hashing.

Ho scritto questa funzione Node.js per eseguire il lato server per rinforzare il motivo per cui non dovremmo eseguire il rollover ma usare una lib esistente (principalmente Bcrypt) ma potrei annullare il mio argomento in quanto non riesco a vedere come questo possa essere facilmente rotto .

L'unico modo che posso immaginare è se l'attaccante può elaborare il sale fisso (pepe), magari ottenendo un pw hash noto, estraendo il sale casuale (avrebbero bisogno di conoscere la lunghezza) e costruendo le proprie tabelle arcobaleno provare a incrinare il sale fisso (questo è molto lungo e ha un'alta entropia).

function checkPw(pw, fullhash) {
    //random one time salt is first 12 chars
    var salt = fullhash.substr(0,12);

    //hashing the full pw, our random salt, the pw and a global fixed salt
    var hashpart = crypto.createHash('sha256').update(salt + pw + process.env.SALT).digest('hex');

    return (hashpart === fullhash.substr(12));
};

Le mie domande sono dov'è il difetto qui? Deve esserci qualcosa di ovvio che mi manca?

cryptography encryption passwords hash password-cracking

posta Trickycm 14.09.2017 - 14:11

fonte

3 risposte

2

Se qualcuno ruba il tuo database, puoi scommettere che possono anche rubare il codice sorgente. Così conosceranno lo schema di hashing, le dimensioni del sale, la posizione del sale. Con queste informazioni, è possibile utilizzare un attacco dizionario contro i tuoi dati.

Il principale punto debole di questa funzione è tempo . Puoi costruire un impianto relativamente economico per bruteforce miliardi di combinazioni al secondo con un paio di GPU. Usando bcrypt puoi definire quanti turni di hashing userete. Un bcrypt con 1000 round è circa 1000 volte più costoso da decifrare.

risposta data 14.09.2017 - 14:43

fonte

-1

Come ha detto @ThoriumBR, se un cracker vuole rompere l'hash, deve prima hackerare il sistema. Quando un utente malintenzionato ha violato un sistema, possiamo assumere che ne ottiene il pieno controllo, indipendentemente dal database che contiene tutta la password o dal sistema che esegue l'operazione di hashing. Dal momento che l'attaccante ottiene tutte le informazioni di cui ha bisogno, ha solo bisogno di iniziare un attacco di dizionario contro il set di hash. Aggiungere un sale fisso sembra aumentare la sicurezza, ma non lo è, perché l'attaccante può semplicemente estrarre il sale fisso dal server. Inoltre, il tuo metodo di hashing ha difetti poiché ha solo un tempo di hash 1, che ogni computer può calcolare molto velocemente in termini di singolo calcolo. Dovresti considerare la funzione KDF come PBKDF2, piuttosto aggiungere un valore fisso.

risposta data 14.09.2017 - 15:59

fonte

Leggi altre domande sui tag cryptography encryption passwords hash password-cracking

Perché i nomi delle classi dovrebbero essere inseriti nella whitelist? Chrome richiede nomi SAN nel certificato. Quando seguiranno altri browser (IE)? [chiuso]

score 3 · Accepted Answer

Ci sono diversi difetti:

Per prima cosa, non vedo perché vorresti "rafforzare l'uso della lib esistente (principalmente Bcrypt)". O si utilizza un algoritmo di hashing della password solido (BCrypt è buono) o no. Se non lo fai, non dovresti tentare di "rinforzarlo", ma invece di passare ad un algoritmo solido.

Secondo: il tuo codice è, come dici tu, Javascript. Javascript implica hashing lato client. L'hashing del lato client è mood, ci sono diverse risposte qui su security.SE che spiegano perché questo è il caso. (Se si sceglie di utilizzare Javascript solo per scopi dimostrativi, ignorare questo punto.)

Terzo: il tuo 'sale fisso' è in genere noto come ' pepe '. Un peperone può aggiungere sicurezza in alcuni casi molto specifici. Un peperone funziona essendo un segreto. Di conseguenza, un peperone non ha alcun beneficio se usato per l'hashing lato client.

Quarto: SHA256 è un hash di uso generale. È progettato per essere veloce. Veloce è esattamente ciò che non vuoi per l'hashing della password.

Quinto: l'operatore di confronto finale è vulnerabile agli attacchi temporali.

Ma tutto si riduce al primo punto: scegli un algoritmo di hashing della password solido (BCrypt) e non tentare di migliorarlo.