Usando MySQL 'encrypt' / crypt () per memorizzare le password?

Question

Usando MySQL 'encrypt' / crypt () per memorizzare le password?

#1 da (1 voti)

3

Mi è stato assegnato il compito di distribuire un'istanza FTP con un backend MySQL per l'archiviazione degli accessi utente.

Guardando online ho trovato Pure-FTPD, che su carta è ottimo. Tuttavia, la documentazione afferma che consente solo queste opzioni di hashing / crittografia per le password:

#MYSQLCrypt md5, cleartext, crypt() or password()

MD5 e cleartext non rientrano nei requisiti, password () dovrebbe essere evitato (secondo la documentazione di MySQL) che lascia crypt ().

L'uso di crypt () per inserire un valore in un database si basa su 'encrypt', che a sua volta è una chiamata di sistema crypt (). Vedi: link

Quindi la domanda è: quanto è sicuro questo metodo di crittografia per archiviare dati sensibili, wikipedia afferma che crypt () -

"Rather than encrypting the password with a key, which would have allowed the password to be recovered from the encrypted value and the key, it used the password itself as a key, and the password database contained the result of encrypting the password with this key."

Che sembra grandioso, ma non riesco a trovare alcuna informazione su questo database 'password' di cui parla, il valore inserito viene anche ridotto a un massimo di 16 bit se ricordo male, che in realtà non sembra sicuro.

Qualsiasi input su questo sarebbe apprezzato, grazie!

encryption passwords hash databases

posta Johndoes 24.10.2015 - 15:03

fonte

1 risposta

Leggi altre domande sui tag encryption passwords hash databases

Quanto tempo sono memorizzate le informazioni su Facebook? [chiuso] Netgear WNDR4300 si arresta in modo anomalo quando viene eseguita la scansione della porta

score 1 · Answer 1

Se leggi la documentazione : SHA1, MD5 e MySQL password () sono supportato solo per motivi legacy e scrypt o crypt (3) è consigliato. Tuttavia, questo non risponderebbe alla tua domanda, quindi vorrei sottolineare quale sceglierei.

crypt (3) Questa è la funzione hashing delle password di Unix (alcuni lo chiamano crittografia). Questo è un codice DES modificato che utilizza un sale a 12 bit basato sull'orologio di sistema, per la diversificazione per utente. Lo svantaggio di questa funzione è che ci vogliono solo otto caratteri ASCII (uguale a 56 bit) come chiave. Tale chiave viene quindi utilizzata per crittografare una stringa a 64 bit di 0 e la cifra DES modificata. L'output viene nuovamente crittografato con la chiave e questa procedura viene ripetuta 25 volte. La ripetizione è stata scelta per rallentare gli attacchi di dizionario. Tuttavia, cracking crypt (3) hash delle password non è davvero un grosso problema e dipende molto dalla forza delle password degli utenti. Tieni presente che questa soluzione risale agli anni '70 e tutti i moderni sistemi Unix / Linux utilizzano algoritmi di hash moderni, come SHA-256 o SHA-512.

scrypt Questo metodo è stato sviluppato da Colin Percival che ha identificato che l'hashing delle password era prevalentemente CPU-hard, ma non di memoria. Il problema quando un algoritmo di hashing della password è solo CPU-hard è, che più CPU sono presenti, più velocemente puoi forzarlo. Il fattore limitante è la memoria e la potenza della CPU. Pertanto scrypt consiste in una serie di funzioni che estendono l'approccio hard della CPU con un approccio hard-memory.

Conclusione Se hai la possibilità di scegliere il metodo di protezione della password, preferisco scrypt anziché crypt (3). La ragione è che crypt (3) è già deprecato e lo scrypt offre maggiore protezione contro gli attacchi brute-force. Tuttavia, dipende anche dal numero di utenti che la tua soluzione dovrebbe servire. Naturalmente, una funzione CPU-Memory-hard non solo userà più risorse durante la forzatura brute, ma anche durante l'autenticazione normale rispetto alle funzioni che non lo offrono.