Sto utilizzando la seguente libreria per l'hashing della mia password.
string password = BCrypt.Net.BCrypt.HashPassword("stackoverflow");
La lunghezza è apparentemente 60 ogni volta. La mia domanda è, sto progettando di memorizzare queste password nel mio database, dovrei memorizzarle come char(60) . In caso contrario, cosa è considerato una buona pratica?
La lunghezza dell'output degli algoritmi di hash non dipende dall'input. Qualsiasi input produce la stessa lunghezza di output.
Da un post in stackoverflow chiesto da z-boss e risposto da Bill Karwin;
MD5 generates a 128-bit hash value. You can use CHAR(32) or BINARY(16)
SHA-1 generates a 160-bit hash value. You can use CHAR(40) or BINARY(20)
SHA-224 generates a 224-bit hash value. You can use CHAR(56) or BINARY(28)
SHA-256 generates a 256-bit hash value. You can use CHAR(64) or BINARY(32)
SHA-384 generates a 384-bit hash value. You can use CHAR(96) or BINARY(48)
SHA-512 generates a 512-bit hash value. You can use CHAR(128) or BINARY(64)
BCrypt generates an implementation-dependent 448-bit hash value. You might need CHAR(56), CHAR(60), CHAR(76), BINARY(56) or BINARY(60)
Il post completo è qui: link
Inoltre, non dimenticare di aggiungere sale alle tue password ( BcryptNet gestisce la salatura automatica). Prima di eseguire l'implementazione, ti consiglio di leggere i post;
La correzione della dimensione dell'attributo può essere un requisito del tuo database / applicazione - se stai memorizzando più di 20 milioni di password usando campi a larghezza fissa per tutti gli attributi nella relazione può essere importante per motivi di prestazioni (sebbene questo sia supportato solo su alcuni RDBMS). OTOH non sappiamo se il tuo database supporta solo record in formato fisso. Supponendo che questo sia un database relazionale o uno schemaless convenzionale, ha molto più senso usare un record di dimensioni variabili (VARCHAR) e specificare un po 'di spazio per l'espansione / aggiornamento - ad esempio VARCHAR (200). Tranne che per i casi limite già menzionati, questo non avrà alcun impatto sulle prestazioni funzionali o misurabili, ma significa che non è necessario modificare lo schema per adeguarsi ad un cambiamento dell'algoritmo in futuro,
Leggi altre domande sui tag cryptography passwords databases