Estoy usando la siguiente biblioteca para codificar mi contraseña.
string password = BCrypt.Net.BCrypt.HashPassword("stackoverflow");
La longitud es aparentemente 60 cada vez. Mi pregunta es, estoy planeando almacenar estas contraseñas en mi base de datos, debo almacenarlas como char(60) . Si no, ¿qué se considera una buena práctica?
La longitud de la salida de los algoritmos de hashing no depende de la entrada. Cualquier entrada produce la misma longitud de salida.
De una publicación en stackoverflow solicitada por z-boss y respondida por Bill Karwin;
MD5 genera un valor hash de 128 bits. Puedes usar CHAR (32) o BINARY (16)
SHA-1 genera un valor hash de 160 bits. Puedes usar CHAR (40) o BINARIO (20)
SHA-224 genera un valor hash de 224 bits. Puede utilizar CHAR (56) o BINARIO (28)
SHA-256 genera un valor hash de 256 bits. Puede utilizar CHAR (64) o BINARIO (32)
SHA-384 genera un valor hash de 384 bits. Puede utilizar CHAR (96) o BINARIO (48)
SHA-512 genera un valor hash de 512 bits. Puede utilizar CHAR (128) o BINARIO (64)
BCrypt genera un valor de hash de 448 bits que depende de la implementación. Tú podría necesitar CHAR (56), CHAR (60), CHAR (76), BINARY (56) o BINARY (60)
La publicación completa está aquí: enlace
Además, no olvide agregar sal a sus contraseñas ( BcryptNet se encarga de la salificación automáticamente). Antes de hacer tu implementación, te recomiendo que leas las publicaciones;
La fijación del tamaño del atributo puede ser un requisito de su base de datos / aplicación: si está almacenando más de 20 millones de contraseñas utilizando campos de ancho fijo para todos los atributos en la relación, puede ser importante por razones de rendimiento (aunque esto es solo soportado en algunos RDBMS). OTOH no sabemos si su base de datos solo admite registros de formato fijo. Suponiendo que se trata de una base de datos relacional convencional o sin esquemas, tiene mucho más sentido utilizar un registro de tamaño variable (VARCHAR) y especificar cierto espacio para la expansión / actualización, digamos VARCHAR (200). A excepción de los casos de borde ya mencionados, esto no tendrá ningún impacto funcional o medible en el rendimiento, pero significa que no necesita cambiar su esquema para acomodar un cambio en el algoritmo en algún momento en el futuro,
Lea otras preguntas en las etiquetas passwords cryptography databases