Modificar las contraseñas antes de almacenar

Aplicar una transformación en las contraseñas antes de incluirlas no hace daño directo a la seguridad siempre que sea inyectivo : dos contraseñas distintas antes de aplicar la transformación seguirán siendo distintas una vez que ambas se transformen. Su "cambio de caracteres" está bien para eso si lo hace correctamente (es decir, tenga cuidado de transformar un byte de valor 255 en un byte de valor 0 que "truncará" la contraseña).

Indirectamente , hay un poco de daño en el hecho de que su transformación adicional es un código adicional, por lo que la complejidad adicional, y la complejidad siempre es mala para la seguridad. Además, si la transformación es computacionalmente costosa, entonces está en desacuerdo con el conteo de iteraciones usado en PBKDF2 / bcrypt (es decir, tiene menos CPU disponible, por lo que debe usar un conteo de iteraciones más bajo).

Una transformación como la que usted imagina solo beneficia a la seguridad en la medida en que el atacante no la conoce, es decir, el atacante no hizo su tarea. Los atacantes básicos y de bajo poder que tuvieron suerte con un ataque de inyección SQL pueden, de hecho, carecer de conocimiento, pero estos atacantes no son los que dan miedo. Tu transformación adicional no disuadirá a los atacantes fuertes, y debes preocuparte por los atacantes fuertes.

aplicadas después de no tienen ninguna influencia en la seguridad, excepto si está utilizando algo como el hashing adicional, en cuyo caso solo está intentando crear una función hash personalizada que, como es habitual, es una mala idea Así que no lo hagas. La forma correcta de usar su CPU es no desperdiciarla en los cambios de carácter vudú y otros rituales; en su lugar, use su CPU para tener una cuenta de iteración bcrypt / PBKDF2 tan alta como sea tolerable para el rendimiento general de su aplicación.

No.

Todo el principio de la criptografía moderna es que usted debe asumir automáticamente que el atacante conoce su esquema de cifrado. Estás tratando tu plan como secreto, lo cual es una mala idea.

Manténgase en bcrypt / PBKDF2 normal.

Las contraseñas de salado ocultan estos patrones. Básicamente sugieres la salazón dos veces. Una vez con tu sal casera y luego dentro de bcrypt.

Esto solo produciría seguridad adicional en un escenario en el que un usuario no conoce su sal hecha en casa, pero sí sabe la sal única que utiliza con bcrypt.

Tal escenario no debería ocurrir. El atacante solo debe conocer su sal única para bcrypt si tiene acceso a todo su sistema y entonces también conoce su sal casera.

En general, es una buena práctica confiar en la función de cifrado en lugar de intentar implementar la suya propia. En este caso, significa confiar correctamente en bcrypt to salt en lugar de tratar de obtener la sal por sí mismo.

Lo que estás haciendo al cambiar los caracteres es agregar un secreto al proceso de hashing. Un atacante debe saber (o debe averiguar) lo que hizo antes de calcular el hash, de lo contrario no puede usar un diccionario para encontrar la contraseña original.

Hay mejores maneras de agregar tal secreto del lado del servidor. Puede cifrar la contraseña ya hash con un cifrado de bloque (cifrado bidireccional). Para obtener su clave, un atacante no solo necesita acceso de lectura a su base de datos (inyección de SQL), sino que además debe obtener privilegios en el servidor para leer la clave.

➽ Al cifrar el hash de contraseña, puede evitar ataques de diccionario, siempre que la clave permanezca secreta. La clave permanece secreta, siempre que el atacante no tenga privilegios en el servidor.

Esta es la misma ventaja que un pimiento puede darte, pero a diferencia del pimiento, el cifrado del hash permite intercambiar la clave, si fuera necesario.

Recuerde que los ataques inteligentes de "fuerza bruta + diccionario" se basan en ser capaces de probar millones de suposiciones por segundo. La implementación correcta de bcrypt / PBKDF2 / scrypt requerirá varias décimas de segundo por intento, lo que hace que la fuerza bruta no sea práctica a gran escala.

El artículo de Ars Technica deja claro en la primera página que estos ataques se realizan contra hashes MD5 sin sal.

Entonces, si desea protegerse contra estos ataques, elegir un alto número de iteraciones para su función de derivación de claves es más importante que cualquier cambio inteligente en la contraseña o hash.