HMAC con la stessa chiave e lo stesso messaggio

1

im utilizzando HMACSHA256 per generare l'hash della password e memorizzarlo. l'obiettivo qui è quello di autenticare gli utenti, ad esempio - salvare le password con hash e convalidare gli utenti ogni volta che è necessario utilizzando le password con hash

// salt is a guid we store seperately, its the id of the user
byte[] GetHash(byte[] password, byte[] salt) 
{
    byte[] saltAndPassword = salt.Concat(password).ToArray();

    var hmac = HMACSHA256();  
    hmac.Key = password;
    var hash = hmac.ComputeHash(saltAndPassword);
    return hash;
}

nota che la chiave è password e l'hash è generato su salt + password

possiamo avere la password come chiave per hash la password di sale +, che comprenderà la sicurezza? quando usi HMACSHA256, dobbiamo necessariamente avere una gestione delle chiavi inorder per usare chiavi separate piuttosto che password?

Inoltre, i tasti devono essere unici in HMACSHA256?

So che le persone spesso suggeriscono funzioni lente come - PBKDF2, Scrypt ecc.

ma usa anche HMACSHA256 sicuro? le persone usano effettivamente un hmac per l'hashing e la memorizzazione delle password? quale sarebbe l'approccio raccomandato per l'hashing e la memorizzazione delle password (se tutto ciò che hai sono password e sali unici)?

scuse per la sfilata di domande :) grazie in anticipo

Modifica

Non sono riuscito a trovare un modo per commentare né la domanda né la risposta (stackexchange mi richiede di avere un rappresentante 50). quindi sto postando il mio commento qui:

@CodesInChaos ciao, grazie per la risposta.

HMAC(password, salt + password)

This is silly but harmless. 1) It uses a variable length value as key. HMAC has some >weird properties when doing that. 2) Why input the password twice?

Hmm, dovremmo fare qualcosa al riguardo?, per renderlo un valore di lunghezza costante (eventuali raccomandazioni)?

Ho pensato che l'hash (sale + password) è sempre meglio dell'hash (password) // l'unico scopo della salatura ??

ma da quello che vedo dalla tua risposta, HMACSHA256 fa cose simili usando la chiave in dotazione?

If you use HMAC for hashing passwords, I'd use the password as message and the salt as >key. This matches HKDF-Extract.

ma, nel nostro caso salt è l'userid, sono esposti, va bene usare salt come chiave che è facile da sapere?.

    
posta user67609 03.02.2015 - 11:42
fonte

1 risposta

2

I know that people often suggest slow functions like - PBKDF2, Scrypt etc..

Ascoltali. Usa scrypt, bcrypt o PBKDF2. Queste funzioni sono progettate per la password di hashing. Vedi Come fare in modo sicuro le password di hash? per i dettagli. Questo è l'approccio raccomandato per le password di hashing.

but is using HMACSHA256 safe too?

È veloce = > la forza bruta è più economica = > è più debole di un hash lento.

Un hash veloce è accettabile solo se si sa che verranno utilizzate solo password complesse (ad esempio 80+ bit di entropia). In pratica, ciò significa che non si consente alle password scelte dall'utente e di generarle utilizzando un computer. A questo punto sono più vicini alle chiavi che alle password tipiche.

do keys have to be unique in HMACSHA256?

Se usato come MAC, non è necessario che le chiavi siano univoche. Lo stai usando come hash della password, quindi non c'è una chiave segreta. I sali dovrebbero essere unici per prevenire attacchi multi-bersaglio, ma le collisioni occasionali non fanno molto male.

// salt is a guid we store separately, it's the id of the user

Questo significa che il sale verrà riutilizzato quando l'utente cambia la sua password. Non ideale, ma neanche un grosso problema.

HMAC(password, salt + password)

Questo è sciocco ma innocuo. 1) Utilizza un valore di lunghezza variabile come chiave. HMAC ha alcune proprietà strane quando lo fa. 2) Perché inserire la password due volte?

Se usi HMAC (salt, password) per le password di hashing, utilizzerei la password come messaggio e la chiave salt. Questo corrisponde a HKDF-Extract.

Hmm, should we do something about it?, to make it a constant length value(any recommendations)?

Se si utilizza la chiave salt e la password come messaggio, la chiave ha una lunghezza fissa. Ma dal momento che queste proprietà non hanno molto impatto pratico, non ti preoccupare troppo se la lunghezza è variabile.

I thought the hash(salt+password) is always better than hash(password) // the sole purpose of salting?

but from what I see from your answer, HMACSHA256 does similar thing using the key supplied?

Poiché HMAC combina già la chiave e il messaggio, non è necessario includere la password in entrambi.

but, in our case salt is the userid, they are exposed, is it okay to use salt as key which are easy to know?

Sì, l'utilizzo di un sale pubblico come input chiave per HMAC va bene. Devi fare delle ipotesi più forti su HMAC di "È un PRF", ma va bene.

    
risposta data 03.02.2015 - 15:10
fonte

Leggi altre domande sui tag