Qualsiasi motivo per rallentare le password hash generate in modo casuale dal nostro sito?

Ok, quindi il sito genera una password casuale per ciascun utente al momento della registrazione. Una domanda importante è se un utente può impostare manualmente la propria password in un secondo momento o se è costretta a utilizzare una password generata dal sito casuale. Diamo un'occhiata ai due casi separatamente.

Password casuali

Per quanto posso dire, questo è lo scenario che stai descrivendo nella domanda. Sfortunatamente, il tuo dev è (principalmente) giusto . Almeno sulla singola iterazione dell'hashing rispetto a un grosso hash lento. La tua domanda ha il sapore di applicare ciecamente le "migliori pratiche" senza considerare a quali erano destinate tali pratiche. Per un brillante esempio di questo, ecco una buona lettura:

Il ragazzo che ha inventato quelle fastidiose regole di password ora rimpiange di sprecare il tuo tempo

Suggerimento

Passa da MD5 a SHA256 , probabilmente aggiungi un sal per utente e forse prendi in considerazione di passare a 32 caratteri. Tuttavia, l'aggiunta di una grande funzione di hashing lento aumenterà il carico del tuo server per poca o nessuna sicurezza aggiuntiva (almeno escludendo qualsiasi altro goof nella tua implementazione).

Comprensione dell'hash come attenuazione della forza bruta

La quantità di lavoro che un hacker con forza bruta che ha rubato il tuo database deve fare per rompere gli hash delle password è all'incirca:

entropy_of_password * number_of_hash_iterations * slowness_of_hash_function

dove entropy_of_password è il numero di possibilità, o "indovinabilità" della password. Finché questa "formula" è superiore a 128 bit di entropia (o un equivalente fattore di lavoro / numero di istruzioni di hash da eseguire), allora sei bravo. Per le password scelte dall'utente, entropy_of_password è abissalmente bassa, quindi hai bisogno di molte iterazioni (come 100.000) di una funzione hash molto lenta (come PBKDF2 o scrypt ) per ottenere il fattore di lavoro in su.

Per "cifre esadecimali di 20 cifre" presumo tu voglia dire che ci sono 16 ²⁰ = 2 ⁸⁰ password possibili, che è inferiore alla "best practice" 2 < sup> 128 , ma a meno che tu non sia un governo o una banca, probabilmente hai abbastanza sicurezza della forza bruta dall'entropia della sola password.

Anche qui i sali non servono a niente perché il pre-calcolo di tutti gli hash è come 2 ⁸⁰ * 32 bit / hash, che è approssimativamente 1 ZB (o 5000 x la capacità di tutti i dischi rigidi del pianeta messi insieme ). Le tabelle Rainbow aiutano un po 'questo, ma francamente, qualsiasi attaccante capace di farlo, merita di impegnarci tutti.

Si desidera ancora hash la password per impedire all'utente malintenzionato di liberare il testo in chiaro gratuitamente, ma una iterazione hash è sufficiente. Passa da MD5 a SHA256 , e forse prendi in considerazione di passare a 32 caratteri.

Password del cervello umano

I commentatori di questo thread sembrano ossessionati dall'idea che, nonostante la tua affermazione che il sito genera password, gli utenti possono infatti scegliere le proprie password.

Non appena l'utente ha la possibilità di cambiare la password, la singola iterazione hash non è un'opzione per memorizzare la password ora a bassa entropia. In questo caso, hai ragione sul fatto che devi fare tutte le operazioni migliori per l'archiviazione delle password.

La salatura

In ogni caso (password scelta dall'utente o casuale) probabilmente vuoi un utente per utente.

Se scelto dall'utente , i sali fanno parte delle migliori pratiche. 'ho detto.

Se casuale , @GordonDavisson sottolinea un attacco davvero bello nei commenti [1] , [2] basato sull'osservazione che una ricerca db è essenzialmente gratuita rispetto a a un calcolo hash. Calcolare un hash e confrontarlo con tutti gli hash degli utenti equivale essenzialmente al confronto con hash di un utente specifico . Finché sei felice di entrare in qualsiasi account (piuttosto che cercare di crackare un account specifico ), più utenti nel sistema, più efficiente è l'attacco.

Ad esempio, supponi di aver rubato la password hash non salda db di un sistema con un milione di account (circa 2 ²⁰ ). Con 2 ²⁰ account, ti aspetti statisticamente di ottenere un riscontro nelle prime 2 supposizioni ⁶⁰ . Stai ancora facendo O (2 ⁸⁰ ) indovina , ma O (2 ⁶⁰ ) hash * O (2 ²⁰ ) db lookups ~ = O (2 ⁶⁰ ) hash.

I sali per utente sono l'unico modo per impedire a di attaccare tutti gli utenti per il costo di attaccare un utente .

Supplementare risposta di Mike Ounsworth , il tuo dev è probabilmente corretto, a patto che stiano generando i loro numeri casuali correttamente.

Se si semina il PRNG che genera malamente queste password, un utente malintenzionato può dedurre lo stato del PRNG per prevedere le password future. Ad esempio, in un caso estremamente patologico in cui si utilizza un Mersenne Twister con uno stato interno che non viene aggiornato tra le sessioni, il seguente attacco è praticabile:

1. Richiedo un numero elevato di account in sequenza
2. Generai un numero corrispondente di byte dal tuo PRNG e me li mando tutti
3. Io uso quei byte per dedurre lo stato interno del tuo PRNG nel momento in cui ha generato le mie password
4. Da questo, deduco lo stato interno del tuo PRNG nel momento in cui hai generato tutte le password successive dell'utente. Ogni futura password che il tuo PRNG genera può essere predetta da me. Inoltre, il MT può essere eseguito all'indietro per generare tutte le sue uscite precedenti da un momento preciso
5. Ora ho calcolato tutte le password in uso dal tuo sistema senza avere accesso al tuo database

Assicurati di utilizzare una fonte di casualità crittograficamente sicura. Il PRNG incorporato nella tua lingua potrebbe non esserlo.

Inoltre, in che modo i tuoi utenti ricorderanno queste password? Generare qualcosa di lungo e imprevedibile porterà gli utenti a risparmiare password.txt sui loro desktop. Se la password è destinata a essere nascosta in un file di configurazione da qualche parte, probabilmente non hai alcun problema reale, ma se si tratta di qualcosa che dovrebbe vivere nella testa di un utente, allora stai sovrastimando in maniera massiccia le capacità degli utenti, e probabilmente inducendoli a inventare i propri difetti di sicurezza.

Come altri hanno già detto, l'inversione dell'MD5 di un numero casuale a 80 bit è un problema difficile, quindi se qualcuno ha ottenuto la tua tabella di hash, probabilmente non sarebbero in grado di accedere agli account utente.

Tuttavia, potresti voler considerare dove gli utenti stanno memorizzando i numeri casuali di 80 bit. Probabilmente non sarà nelle loro teste. Caso migliore, si trova in un'app per il repository di password o portachiavi ragionevolmente sicuro. Nel peggiore dei casi, avranno un file con PASSWORDS_FOR_YER_APP.TXT nella loro home directory.

MD5 come dici tu è insicuro, principalmente a causa di scoperte del 2013 che gli permettono di essere attaccato dalla collisione in 2 ^ 18 volte (Apparentemente meno di un secondo su macchine moderne).

Indipendentemente dal fatto che la password venga utilizzata su altri siti, il tuo sito è ancora insicuro. Solo perché è casuale e quindi non apparirà sulle tabelle di ricerca di alcun tipo, non significa che non possa essere rotto tramite collisione. Ciò significa che se qualcuno ottiene l'hash, possono facilmente determinare qualcosa che funzionerà come password, assumendo che tu controlli gli hash.

Come altri hanno già detto, usa un metodo migliore - la famiglia SHA è buona, ma molti preferiscono SCrypt e BCrypt per le password, e se le password generate casualmente che hai a che fare con te probabilmente non avranno bisogno di sale.