Come applicare correttamente un peperone a bcrypt?

Question

Come applicare correttamente un peperone a bcrypt?

#1 da (24 voti)

33

Update: There is a better way to add a server side key, than using it as a pepper. With a pepper an attacker must gain additional privileges on the server to get the key. The same advantage we get by calculating the hash first, and afterwards encrypting the hash with the server side key (two way encryption). This gives us the option to exchange the key whenever this is necessary.

Per le password di hashing in un database, vorrei aggiungere un pepe alla funzione hash. Naturalmente questo pepe sarà aggiunto al sale unico.

Il motivo per cui voglio aggiungere un pepe è che impedisce un attacco del dizionario, nel caso in cui l'autore dell'attacco abbia solo accesso al database, ma non al server (tipico di Sql-Injection). Secondo me è meglio di un hash senza pepe, anche se il pepe è solo hardcoded (per evitare la complessità del codice).

Ora mi chiedo, come il pepe dovrebbe essere applicato correttamente, è corretto semplicemente aggiungere il pepe alla password prima dell'hashing?

1. Concatenare password e pepe

$passwordHash = bcrypt($password . $pepper, $salt);

Un motivo contro questo potrebbe essere, che le password più grandi del limite di bcrypt (55 caratteri) non otterranno il pepe, anche se le password di questa lunghezza non sono comunque propense in un dizionario. A causa di questo limite, il pepe viene aggiunto dopo la password e non prima. Un altro motivo potrebbe essere che, se l'attaccante conosce il peperone, conosce anche la fine di tutte le nostre password pepate.

2. Combina password e pepe con hash

$passwordHash = bcrypt(hash('sha256', $password . $pepper), $salt);

Quindi potremmo usare una funzione di hash per combinare password e pepe, prima dell'hashing. È appropriato usare sha256, o quale funzione di hash sarebbe ideale, quando vogliamo usare bcrypt in seguito?

3. Combina password e pepe con hmac

$passwordHash = bcrypt(hash_hmac('sha256', $password, $pepper), $salt);

Spesso un hmac è la soluzione consigliata, c'è qualche vantaggio sull'uso diretto di SHA256? Dal momento che vogliamo solo combinare password e pepe, e la sicurezza viene dopo dal bcrypt, non vedo alcun vantaggio apparente.

Qualsiasi suggerimento utile è molto apprezzato.

passwords hash bcrypt

posta martinstoeckli 07.10.2012 - 22:47

fonte

1 risposta

Leggi altre domande sui tag passwords hash bcrypt

Può o dovrebbe la whitelisting sostituire la crittografia? Come posso spiegare "zero knowledge proof" a un utente finale?

score 24 · Accepted Answer

I tuoi tre metodi sono corretti. Il terzo (con HMAC) potrebbe essere un po 'più "elegante", matematicamente parlando: renderebbe più semplice dimostrare la sicurezza della costruzione, relativamente a quelli di bcrypt e HMAC.

Attenzione però ai byte null. Una determinata implementazione di bcrypt potrebbe aspettarsi una stringa di caratteri e fermarsi al primo byte del valore 0, che potrebbe verificarsi nell'output di SHA-256 o HMAC (o come parte della chiave binaria che si usa come pepe), ignorando tutti i byte successivi. Sarebbe un grave problema e tu non lo noteresti. Per evitare questo problema, potresti voler codificare Base64-codificare l'output SHA-256 o HMAC prima di assegnarlo a bcrypt (l'output SHA-256 con codifica Base64 è di 44 caratteri, sempre sotto il limite di bcrypt).