MD5 prima di PBKDF2 su software legacy

Question

MD5 prima di PBKDF2 su software legacy

#1 da (1 voti)

0

Sto mantenendo un software legacy che utilizza MD5 nel modo seguente:

Il client richiede un massimo di 16 byte durante l'autenticazione di un account.
Il server genera un sale di 16 byte, lo collega all'account e lo invia al client.
Il client aggiunge il 16 byte salt su una password, fa MD5 (passa + sale) e invia l'hash MD5 attraverso la rete.
Mentre il server memorizza la password in chiaro nel database, recupera solo la password e confronta MD5 (database_pass + salt) con l'MD5 ricevuto (pass + sale) dal client.

Poiché non posso modificare il funzionamento del client, stavo pensando a cosa avrei potuto fare per interrompere la memorizzazione della password in chiaro sul database. L'idea alla quale sono arrivato era, invece di memorizzare la password in chiaro sul database, per memorizzare il sale di 16 byte utilizzato dal client e, alla registrazione, generare MD5 (pass + sale) e utilizzare questo MD5 come input per PBKDF2 con 64 byte di sale e HMAC-SHA512, 10000 iterazioni. Quindi, per autenticare, riceverei MD5 (pass + sale) dal client e PBKDF2 per controllare con l'hash PBKDF2 memorizzato.

Il mio dubbio è, questo renderà il mio server più sicuro? Dato che la password e l'MD5 (pass + sale) non verranno memorizzati nel database, la password non sarà più accessibile se il mio database perde, ma c'è un problema con l'utilizzo di MD5 prima?

Ci sono possibili problemi con questo approccio? C'è un approccio migliore ad esso?

L'unico inconveniente che posso pensare è che non avrò accesso alla password del client dopo un'autenticazione corretta, quindi cambiare il sistema di autenticazione in seguito sarà difficile. Avrò MD5 (pass + sale), ma cambiare il sale sarebbe impossibile.

Voglio farlo bene perché non potrò cambiare il sistema in seguito. Qualsiasi aiuto è apprezzato.

authentication passwords password-management password-policy pbkdf2

posta RenatoUtsch 09.03.2015 - 04:13

fonte

1 risposta

Leggi altre domande sui tag authentication passwords password-management password-policy pbkdf2

Come fanno le app a sapere se c'è un problema con ssl? Metodi di connessione WPS e WPA2

score 1 · Accepted Answer

Penso che ci sia un difetto grave nel tuo suggerimento: a meno che non mi lasci il segno, il tuo " salt "non è affatto un sale: è una sfida e, come tale, dovrebbe essere generati casualmente ogni volta che un client tenta di autenticarsi.

Se questo è il caso, non è possibile utilizzarlo come input per la funzione pbkdf2. Non funzionerà. Se è non il caso, quindi a meno che non si stia già utilizzando una connessione sicura tra client e server, lo schema di autenticazione è seriamente imperfetto: è vulnerabile a un attacco di riproduzione e annusa tanto quanto una password in chiaro.

In generale, è sempre meglio non provare a implementare questo tipo di schema: utilizzare una connessione sicura (TLS) tra il client e il server per proteggere i dati in movimento e utilizzare PBKDF2 (o qualsiasi standard key-derivation function che corrisponde ai tuoi requisiti: BCRYPT , SCRYPT , ecc.) per proteggere i dati a riposo. Se hai davvero bisogno di una challenge-response, usa SCRAM .

Nel tuo caso, sfortunatamente, l'implementazione di SCRAM richiederebbe un cambiamento nel modo in cui il client funziona.

L'alternativa migliore sarebbe per te per memorizzare la password in forma (reversibile) crittografata. Tuttavia, proteggere le chiavi in modo corretto è un'operazione molto complessa: difficile da ottenere correttamente e facile da sbagliare. È difficile dare suggerimenti per questo tipo di implementazione dal momento che dipende molto dal valore delle risorse che stai proteggendo (ti suggerirei comunque di prendere in considerazione la possibilità di spostare l'autenticazione su un sistema completamente diverso che interagisce solo con quello principale attraverso un'interfaccia rigorosa)