È sicuro usare HMAC con una chiave pubblica allo scopo di salare?

Il nome utente (o l'ID utente) non è corretto. I sali dovrebbero essere unici per ogni combinazione di nome utente + password, ciò significa che se l'utente cambia la password, anche il sale dovrebbe cambiare

I sali dovrebbero essere generati casualmente al cambio della password (o quando l'utente si registra) per esempio leggendo da /dev/random o qualche funzione che genera numeri casuali crittografici. A proposito della lunghezza del sale, dovrebbe essere abbastanza lungo da garantire che non si ripeta mai

Risposta breve

No. Vedi: Non lanciare la tua sicurezza .

Risposta pedante

Hai modificato diversi termini.

Non è un HMAC se la chiave è pubblica

Un HMAC richiede una chiave segreta (a volte chiamata pepe) in contrasto con un sale, che è pubblico . Altrimenti non è un HMAC; è solo un hash.

Un uso comune di un HMAC è quello di creare un'impronta digitale resistente alla manomissione al fine di fornire l'integrità del messaggio. Non è utilizzato per l'archiviazione delle password.

Non pensare che stai parlando di un attacco di dizionario

Lo scopo di utilizzare un hash salato per memorizzare una password non è quello di mitigare gli attacchi del dizionario. Lo scopo è quello di contrastare gli attacchi che utilizzano una tabella arcobaleno . Il sale non influenza un puro attacco al dizionario; l'unica attenuazione consiste nell'utilizzare una password che non è nel dizionario, ad es. richiedendo caratteri speciali o richiedendo password più lunghe.

Penso che tu stia chiedendo ...

Penso che potresti chiedere "È OK utilizzare un algoritmo HMAC con una chiave pubblica (invece di una corretta funzione di hashing della password, come BCrypt ) per memorizzare un hash della password?" In tal caso, la risposta è ancora NO . È necessario utilizzare algoritmi di hashing della password, non altri algoritmi di hashing , per password hashing, perché hanno caratteristiche specifiche del problema. Ad esempio, sono volutamente lenti e / o forniscono parametri che consentono di specificare il numero di iterazioni richieste, il che aumenta la potenza di calcolo richiesta per gli attacchi di dizionario e può renderle molto più difficili rispetto agli hash ordinari che funzionano con un singolo passaggio.

Va bene usare l'ID utente come salt?

Mi dispiace, no. Causa alcuni problemi:

1. Crea un problema se l'utente cambia il suo ID (l'hash deve essere ricalcolato)
2. L'ID utente potrebbe non essere abbastanza lungo da contrastare gli attacchi
3. Lo stesso ID utente potrebbe essere utilizzato per diversi servizi, rendendo facile per l'hacker sapere se anche la stessa password è stata utilizzata
4. L'hacker potrebbe comporre una serie di tabelle arcobaleno in base a un elenco di ID utente comuni.

Inoltre, vedi questo articolo decente sull'argomento , che afferma:

A good rule of thumb is to use a salt that is the same size as the output of the hash function. For example, the output of SHA256 is 256 bits (32 bytes), so the salt should be at least 32 random bytes.

È molto pericoloso. Il tuo uso proposto di HMAC, dal punto di vista della sicurezza, è identico a l'esperimento in questo video - quasi banale in pratica.

In aggiunta a ciò, usare il nome utente come sale è un problema, anche se minore. Significa che la stessa combinazione di nome utente + password su due siti diversi produce lo stesso tag di verifica, che consente a qualcuno che ottiene i database delle password di dire che questo utente riutilizza le password attraverso i siti. Questa è una delle ragioni per cui i sali casuali sono probabilmente i migliori.

Questa è la domanda sbagliata. Stai inventando il tuo schema di archiviazione sicuro delle password. Dovresti fermarti immediatamente. Utilizza un buon metodo controllato come argon2, scrypt, bcrypt o, nel peggiore dei casi, pbkdf2 con i parametri regolati in modo da occupare tutto il tempo e la RAM della CPU che ti puoi permettere mentre stai seguendo le richieste.

NO, NON È SICURO

Questa risposta è di riassumere i risultati degli altri che hanno contribuito qui.

1. HMAC non è progettato per essere un algoritmo di hashing della password . Nonostante il fatto che l'algoritmo sia molto simile a come Linux calcola gli hash delle password nel file / etc / shadow , HMAC esegue una sola iterazione, mentre Linux fa centinaia o migliaia di iterazioni, quindi HMAC manca la lentezza dei requisiti. Per favore controlla la domanda di riferimento sull'hash di password
2. Utilizza bcrypt o un altro algoritmo di hashing della password specifico, con un numero considerevole di iterazioni e sale abbastanza lungo.
3. Il sale dovrebbe avere almeno la dimensione delle funzioni di hash sottostanti dimensioni blocco
4. L'ID utente non è salato.
5. Il sale dovrebbe essere cambiato ogni volta che la password viene cambiata.

NO

Non farlo, è sciocco che tutti abbiano accesso alla parte pubblica di una coppia di chiavi asimmetriche. Ecco l'idea.

Un sale non dovrebbe mai essere rivelato a nessuno o puoi usare un tavolo RAINBOW per craccarlo. SHA-1 cade molto facilmente in questo modo.

link