Buona pratica: memorizzazione di password in generale

-3

Ho una domanda totalmente teorica su di te oggi - qual è la pratica "migliore" per memorizzare le password? [Il migliore in termini di sicurezza e prestazioni]

Solitamente, in particolare gli sviluppatori PHP tendono a memorizzare le credenziali dell'utente sia in testo normale sia come hash, usando MD5 o SHA1 e i loro successori. Gli sviluppatori web e i cuochi di software più intelligenti aggiungono addirittura un po 'di sale alla password prima dell'hashing.

Gli sviluppatori Android di solito sembrano memorizzare in testo normale, per quanto ho visto fino ad ora, facendo affidamento ingenuamente sul concetto di diritti utente di Android, anche sostenendo che il rooting dei dispositivi è colpa dell'utente.

Ci sono molte pratiche diverse là fuori. Testo semplice per quelle applicazioni, in cui gli sviluppatori si affidano alla sicurezza della piattaforma o vogliono che l'utente recuperi la propria password. Hashing in cui gli sviluppatori fanno affidamento sull'integrità dell'algoritmo di hashing, ignorando gli attacchi di collisione e così via. Salted Hashings dove gli sviluppatori leggono che l'hashing semplice è una cosa negativa a causa delle tabelle arcobaleno. Ci sono anche alcuni sviluppatori là fuori che usano la crittografia reale, ma di solito la chiave è da qualche parte recuperabile.

La mia idea era di usare AES (o crittografia simmetrica [ancora non spezzata] in generale, come blowfish e così via), criptando la password imbottita (per nascondere la lunghezza della password) con un prefisso salt. La chiave sarebbe la password dell'utente, che dovrebbe rendere impossibile il recupero e la verifica della password senza la password.

Mi chiedo perché la pratica abituale differisca da quell'idea - quindi dov'è la colpa? La complessità non dovrebbe essere così alta, perché ci sono buone implementazioni di AES là fuori, anche implementazioni hardware. Non ci sono conflitti di hash su questo.

Quindi ho ragione che nessuno potrebbe usare un dump di dati con quelle password per qualcosa di diverso da bruteforcing? [Ovviamente ci sono altri attacchi, che sono a prescindere dalla memorizzazione della password di back-end, quelli non sono argomenti di questa domanda]

Può essere che questa idea sia abbastanza simile e correlata a bcrypt, ma senza più iterazioni?

    
posta pmedia 11.02.2013 - 00:06
fonte

2 risposte

7

È buona norma non memorizzare le password ma qualcosa che viene utilizzato per verificare una password. Si chiama hashing .

La tua proposta è solo una funzione hash personalizzata creata con AES, che non era pensata per quello. Gli algoritmi crittografici personalizzati e fatti in casa sono la rovina della sicurezza. Smettila. La resistenza di AES come funzione di crittografia non dice (quasi) nulla sulla sua resistenza come elemento in una funzione di hash (eccetto per quella strana cosa chiamata attacchi a chiave correlata che non hanno importanza per la crittografia, ma possono uccidere una proposta di funzione hash e AES è un po 'fragile in quell'area).

La tua idea è molto simile a bcrypt tranne che evita tutto ciò che rende bcrypt un buon algoritmo, cioè la lentezza configurabile (le "iterazioni") e il sale , entrambi importanti per la sicurezza.

Collisioni non hanno nulla a che fare con la sicurezza degli schemi di hashing delle password. Questi funzionano sulla resistenza alle pre-analisi .

    
risposta data 11.02.2013 - 00:14
fonte
4

Hai sostanzialmente proposto di creare un hash unidirezionale da un codice a blocchi usando lo schema:

H(x) = AES(x,x)

Cosa c'è che non va? Tutto ciò che non va usando solo una funzione di hash standard, come il raw SHA- *, oltre al fatto che si tratta di un design personalizzato. Nel migliore dei casi non migliora con una normale funzione di hash, nel peggiore ha qualche difetto che una funzione standard di hash non avrebbe.

(Si noti che non c'è nulla di intrinsecamente sbagliato con la progettazione di hash basati su cifrari a blocchi. Può essere fatto, anche se non sto approvando lo schema proposto qui.)

Come minimo, gli hash delle password devono essere salted per prevenire attacchi di dizionario e avere un fattore di lavoro scalabile che consente all'hacker di effettuare una spesa configurabile per l'attaccante di energia facendo il loro attacco.

    
risposta data 11.02.2013 - 00:19
fonte

Leggi altre domande sui tag