Un modo sicuro per archiviare password decifrabili

Question

Sto facendo un'applicazione in PHP e vi è la necessità che sia possibile decrittografare le password per evitare problemi in futuro con il passaggio da un database utente all'altro. Considera che non è possibile modificare il metodo di password di questo futuro sistema e ho bisogno di password in testo semplice per avere le password generate.

Il piano è di crittografare la password dell'utente con una chiave pubblica che è memorizzata sul server. L'autenticazione viene eseguita crittografando l'input e confrontando i risultati. Non c'è nessuna decrittazione fatta. La chiave privata in grado di decifrare viene archiviata fuori sito per un utilizzo successivo.

Quale algoritmo di crittografia/decrittografia suggeriresti? Le password crittografate sono ancora sicure come l'hashing (MD5/SHA1) se si considera che la chiave privata non è disponibile per l'utente malintenzionato?

Answer 1

Essere in grado di decrittografare le password è una cattiva idea (e probabilmente non c'è alcun modo per farlo sarebbe molto meglio che archiviarle in modo non criptato). Sembra che il tuo problema principale sia riuscire a usare le password se cambi il tuo metodo di archiviazione. Fai semplicemente ciò che fa Linux, memorizza come stai tagliando la password con la password. Quindi, ad esempio $ 1 $ $ $ hash è MD5. In questo modo, se decidi di cambiare il modo in cui vengono memorizzate le password, puoi comunque controllare le vecchie password (e se qualcuno accede correttamente, puoi aggiornare la loro password con il nuovo hash).

Answer 2

Per la maggior parte delle applicazioni è più che sufficiente memorizzare gli hash SHA-1 delle password.

Sì, ci sono collisioni note nella maggior parte degli algoritmi di hashing, ma ciò non implica un vettore di attacco effettivo. Soprattutto quando stai salando gli hash.

Per il tuo sale: archivialo in un file di configurazione che non è accessibile dall'esterno ma può essere letto dall'installazione di PHP.

Answer 3

Non decrittografare la password. Se è necessario modificare il sistema di password in futuro, aggiungere un campo chiamato storage_type (o qualsiasi altra cosa).

Quindi, quando è necessario modificare le password, si controlla se è una vecchia password. In questo caso, al prossimo accesso, è possibile modificare la codifica della password. Altrimenti, accedi con il nuovo sistema.

Answer 4

sarò riformulare l'approccio di Jammer -

1. Generare una coppia di chiavi pubblica/privata. Hard-code la chiave pubblica sul tuo server web. Conserva la chiave privata in un armadietto fisico, fuori dalla portata del server web/database/di qualsiasi sviluppatore.
2. Quando l'utente si registra, crittografa la password + sale utilizzando la chiave pubblica. Questo passaggio è identico all'utilizzo di un algoritmo di hash. Memorizza la password crittografata + sale nel database.
3. Quando si desidera verificare la password, crittografarla nuovamente e confrontarla con il valore memorizzato nel database.

Se un utente malintenzionato ottiene il database, non può decrittografare le password perché non ha la chiave privata. Non può ottenere la chiave privata perché si trova in un caveau di una banca fuori dalla sua portata. Due password identiche verranno comunque archiviate diversamente nel database a causa del sale.

Non è consigliabile utilizzare l'approccio di cui sopra perché in qualsiasi momento nel futuro qualcuno potrebbe abusare della chiave privata e ottenere l'accesso a tutte le password.

Ma se si garantisce che la chiave privata rimarrà sempre privata, quindi non vedo un difetto tecnico.

Potrei sbagliarmi, ovviamente.

Answer 5

L'unico problema che vedo è che la maggior parte del codice di crittografia a chiave pubblica-privata là fuori crittografa una chiave simmetrica utilizzando la chiave pubblica e si basa sulla decrittografia della chiave privata, quindi usa la chiave simmetrica per crittografare il messaggio.

Si desidera utilizzare la chiave pubblica per crittografare direttamente la password + sale.

Quindi gli attacchi contro il sistema si riducono a:

1. Attacchi contro pubblico/crittografia a chiave privata
2. Gli attacchi contro il vostro negozio di chiave privata.