PBKDF2 sale strong per l'hashing lato client

6

Che cosa dovrei usare come sale sicuro / strong per l'hashing PBKDF2 quando sale non è disponibile per l'uso prima dell'accesso in quanto sarà javascript lato client per l'utente hash + passare con PBKDF2? Userò sha (user + pass) come salt per pbkdf2.

Se utilizzo un salt generato a caso, dovrei memorizzarlo in DB, ma quando l'utente vuole accedere, l'utente non avrà sale per crittografare la sua password con sale prima di inviarlo al server per la verifica.

Quindi, qual è la soluzione buona / sicura / sicura qui? Post scriptum Sto cercando di ottenere il protocollo "zero knowledge". Inoltre sto già usando SSL.

    
posta JustACPPFan 11.01.2015 - 02:04
fonte

1 risposta

7

Per prima cosa, assicurati di leggere questa risposta alla domanda "Hash password lato client" , prestando particolare attenzione all'ultimo paragrafo.

Inoltre, ti preghiamo di capire che il javascript lato client sarà incredibilmente lento con PBKDF2 rispetto al buon codice lato server. Cerca almeno di trovare un'implementazione PBKDF2 che utilizzi HMAC-SHA-512 come base.

Detto questo, se vuoi dare tranquillità all'utente, va bene; fai quanto segue:

  • Ospite PBKDF2 lato client per un conteggio iterazione noto, "alto".
    • Doppio punto bonus se l'utente è autorizzato a selezionare il conteggio iterativo!
    • Inserisco molte virgolette perché dubito che il tuo codice javascript sarà abbastanza veloce da fare decine o centinaia di migliaia di iterazioni nel tempo in cui puoi accaparrare abbastanza della tua base di utenti, in particolare su dispositivi mobili più economici.
    • Un buon hash del nome utente e della password come salt non è un granché, anche se è meglio se il tuo codice inserisce il nome utente alla massima lunghezza possibile e lo mette prima.
      • In questo modo, "utente1" e "password" non fanno lo stesso sale di "utente" e "1password"!
      • Ovviamente non esiste una lunghezza massima della password, tranne ciò che è causato dal tuo software di back-end; SQL Server, ad esempio, ha un massimo di 8000 byte per il lavoro di stringa "meno inefficiente".
  • Invia l'hash da solo al server
    • che poi genera un sale crittografico casuale di 12-16 byte
    • e quindi usa PBKDF2 con un numero di iterazioni molto più elevato per hash l'hash passato
      • si spera di nuovo HMAC-SHA-512 per le operazioni a 64 bit per ridurre il vantaggio proporzionale degli attacchi GPU offline.
      • perché quindi qualcuno che ottiene il database delle password trapelate deve ancora eseguire il lavoro di un attacco contro una funzione di hashing della password per accedere, piuttosto che semplicemente inviare l'hash generato dal client che hanno rubato e accettarlo così com'è.

Ricorda con l'hashing della password PBKDF2 in particolare, non chiedere mai una dimensione di output più grande della dimensione di output dell'hash base nativo. Più piccolo va bene se sei davvero, davvero preoccupato per l'archiviazione; per esempio, richiedendo solo 32 byte di output nativo a 64 byte di PBKDF2-HMAC-SHA-512.

  • 20 byte per SHA-1
  • 32 byte per SHA-256
  • 64 byte per SHA-512
risposta data 11.01.2015 - 09:31
fonte

Leggi altre domande sui tag