Esiste un modo migliore per sfruttare gli attuali algoritmi "approvati", "comprovati" e di memoria / cpu costosi durante l'uso di sali e peperoni?

3

Ho letto dei concetti presentati in queste due domande:

Pre-hash password before applicando bcrypt per evitare di limitare la lunghezza della password

Avrebbe senso usare Bcrypt e PBKDF2 insieme?

Penso di aver realizzato un'implementazione che combini i concetti presentati in entrambe le domande, pur fornendo diversi livelli di sicurezza.

Domande

  1. Questa implementazione è relativamente sicura rispetto alla maggior parte degli altri?
  2. Mi sono sparato ai piedi concatenando più funzioni in questo modo?
  3. Esiste un modo migliore per sfruttare gli attuali algoritmi "approvati", "provati" e costosi?
  4. Come posso migliorare questa implementazione?
  5. C'è un punto in cui i valori di sale e pepe sono abbastanza grandi da rendere più difficile il cracking degli hash richiedendo più memoria e / o elaborazione?

Preoccupazioni

  1. L'uomo negli attacchi centrali
    • SSLStrip
    • spoofing ARP, dirottamento DNS e funzionamento come proxy HTTP
      • Chiusura della connessione SSL sul lato dell'attaccante e invio del traffico HTTP all'utente
  2. Password di testo normale gestita dal codice server
  3. Problemi con le tabelle e i compleanni arcobaleno
  4. Algoritmi non provati
  5. Calcolo rapido ed efficiente degli hash
  6. Credenziali veramente lunghe
  7. Mancanza di entropia adeguata
  8. I risultati del dump del database di autenticazione nella divulgazione di sali e peperoni
  9. Archiviazione di e-mail di testo normale

Soluzioni

  1. Non inviare mai la password in chiaro sul filo e utilizzare SSL solo attraverso il sito
  2. Salta e cancella la password prima di inviarla al server
  3. I peperoni unici dell'utente vengono applicati sul server
  4. La catena di hashing termina con PBKDF2, un algoritmo controllato da RSA
  5. L'hashing chain utilizza bcrypt, in quanto richiede 4kB di memoria
  6. Qualsiasi stringa di input su bcrypt viene hash con SHA-512 per mantenere il numero di caratteri di input al di sotto del limite
  7. Salt and peppers saranno stringhe lunghe e casuali
  8. Memorizza i sali e i peperoni privati su un altro servizio accessibile solo dall'API interna
  9. Memorizza gli hash degli indirizzi e-mail e le password sui server che gestiscono il traffico pubblico

Componenti

Algoritmi

SHA-512, bcrypt, PBKDF2

Sali pubblici

public_salt

pepe privato

email_pepper, bcrypt_pepper, pbkdf2_pepper

Utente globale

public_salt, email_pepper

Utente unico

bcrypt_pepper, pbkdf2_pepper

Processo

  1. L'utente immette l'indirizzo email e la password in un modulo Web e li invia per l'accesso.
  2. L'indirizzo email e la stringa della password vengono sottoposti a hash utilizzando PBKDF2 (separatamente) con public_salt e le due chiavi risultanti a 1024 bit (email_key, password_key) vengono inviate al server su SSL.
  3. Il server ha cancellato di nuovo email_key con PBKDF2 utilizzando email_pepper con un numero di iterazioni più elevato per ottenere stored_email_key.
  4. Il server quindi interroga un servizio solo interno per richiedere i peperoni unici memorizzati per stored_email_key e riceve bcrypt_pepper e pbkdf2_pepper.
  5. password_key viene sottoposto a hash con SHA-512 per ridurre la lunghezza della chiave, quindi bcrypt non tronca l'input, con conseguente riduzione_hash.
  6. reduced_hash viene quindi sottoposto a hashing usando bcrypt, con bcrypt_pepper, risultando in bcrypt_hash.
  7. bcrypt_hash viene quindi sottoposto a hash utilizzando PBKDF2 con pbkdf2_pepper, dando come risultato l'hash finale della password memorizzata.

Panoramica

email_key = PBKDF2(email, public_salt)
password_key = PBKDF2(password, public_salt)
POST: keys -> SSL -> server
stored_email_key = PBKDF2(email_key, email_pepper)
server gets bcrypt_pepper, and pbkdf2_pepper
reduced_hash = SHA-512(password_key)
bcrypt_hash = bcrypt(reduced_hash, bcrypt_pepper)
pbkdf2_hash = PBKDF2(bcrypt_hash, pbkdf2_pepper)

Compounded

Password - pbkdf2(bcrypt(sha512(pbkdf2(password, public_salt)), bcrypt_pepper), pbkdf2_pepper)
Email address - pbkdf2(pbkdf2(email_address, public_salt), email_pepper)

Informazioni sulla memoria degli indirizzi e-mail

  1. Gli indirizzi email sono necessari solo per notifiche, reimpostazioni di password e newsletter.
  2. Gli indirizzi email verranno memorizzati come un hash PBKDF2 su qualsiasi sistema o cluster che gestisca qualsiasi traffico pubblico.
  3. Gli indirizzi e-mail verranno archiviati crittografati su un servizio accessibile tramite un'API disponibile solo al codice interno che deve inviare e-mail ai destinatari.

Mi rendo conto che potrebbe essere eccessivo, ma voglio davvero garantire che le password e gli indirizzi e-mail siano gestiti e archiviati correttamente.

Specifiche

Sto ancora discutendo su quali valori utilizzare per il numero di iterazioni su ogni fase del processo. Ovviamente, sto usando un numero maggiore di iterazioni sul server rispetto a javascript.

Sto pensando di generare chiavi a 1024 bit dove viene utilizzato PBKDF2, oltre a usare sali di 2048 bit o più grandi.

    
posta clay richardson 02.11.2012 - 02:29
fonte

1 risposta

4

La prima regola di sicurezza è: Non eseguire il crypto della propria .

Sei arrivato con uno schema complesso, che non migliora davvero nulla rispetto alle migliori pratiche. Inoltre, non sono sicuro che tu sia chiaro su cosa sia un sale o pepe, e perché sia usato: un sale è un insieme casuale di byte di lunghezza fissa e non è considerato un segreto. Un pepe è una chiave (segreta).

Hash lato client
I valori di hash sul lato client non ti danno nulla, perché:

  1. Stai già utilizzando SSL, quindi tutto viene crittografato prima di essere inviato tramite il filo
  2. Se hai un hash, ad esempio una password, sul lato client, l'hash della password diventa effettivamente la password.

Indirizzi email Solitamente si desidera che l'indirizzo e-mail dell'utente sia in forma reversibile / leggibile, in quanto è necessario in un secondo momento per comunicare con l'utente. Se hai solo un valore derivato, non puoi contattarli.

Password pre-hash
BCrypt tronca qualsiasi password a 55 byte di input (escluso il sale ). 55 byte potrebbero non sembrare molto alla luce dei valori comunemente quotati di 128 bit, 256 bit o anche 1024 bit. Tuttavia, le password comuni sono la realtà di lunghezze nell'intervallo da 6 a 10 caratteri.

Se si desidera consentire valori più lunghi, vorrei semplicemente usare

bcrypt(sha512($password)); *

La necessità di un valore del pepe è discusso qui . Se decidi di voler memorizzare le tue password usando sia pepe che amp; sale, usa:

bcrypt(hash_hmac('sha256', $password, $pepper)); *

Come raccomandato qui .

*) In entrambi gli esempi, presumo che tu usi un'implementazione di BCrypt che crea automaticamente un salt

    
risposta data 02.11.2012 - 08:18
fonte

Leggi altre domande sui tag