¿Fuerza bruta MD5 en un hash defectuoso?

Hay uno o dos conceptos erróneos en tu pregunta.

Como hash de mensaje (archivo, etc.), MD5 no es inseguro debido a la "capacidad de fuerza bruta y obtención del resultado". Los hashes criptográficos tienen tres propiedades de seguridad:

1. Una forma: dado un hash, es imposible encontrar un mensaje con ese hash.
2. Integridad: dado un mensaje, es imposible encontrar otro mensaje con el mismo hash.
3. Resistencia a la colisión: es imposible encontrar dos mensajes con el mismo hash.

La única propiedad de MD5 que ahora está rota es la tercera, la resistencia a la colisión. Es posible elaborar mensajes con el mismo hash. Sin embargo, para un mensaje que no está especialmente diseñado, todavía no es posible encontrar otro mensaje con el mismo hash. No obstante, no se recomienda el MD5, en parte porque es plausible que pronto se encuentren mejores ataques que anulen la integridad, y en parte porque muchos sistemas que dependen principalmente de la integridad también dependen de la resistencia a la colisión contra algunos ataques de alto nivel.

Tomar MD5 y modificar la salida no ayudaría de ninguna manera con la resistencia a la colisión, ya que una colisión para MD5 también sería una colisión para su hash modificado. Tampoco ayudaría con la integridad, por la misma razón. Por lo tanto, su propuesta no puede hacer nada contra los defectos conocidos de MD5.

Si modificas un hash MD5, podría ser más difícil encontrar un mensaje con el hash. ¡Pero solo si la transformación que haces es difícil de invertir! Por ejemplo, si realiza alguna transformación fija como voltear algunos bits, es inútil. Si encripta el hash, eso podría hacerlo, o no: depende de la propiedad de seguridad que desee lograr. Recuerde que no se sabe que la propiedad unidireccional para MD5 esté rota.

Entonces ¿qué propiedad de seguridad quieres lograr?

Si está utilizando MD5, es un hash de contraseña , entonces MD5 no es su único problema, ni su problema principal. Para un hash de contraseña, las búsquedas de fuerza bruta son una preocupación. Ninguno de los hash habituales del mensaje es adecuado como contraseña , porque son rápidos. Los hash de contraseña deben ser lentos , precisamente para hacer que las búsquedas de fuerza bruta sean más difíciles: golpean al atacante más fuerte que el usuario legítimo, ya que el atacante debe probar millones de posibilidades. Afinando MD5 no puede ayudar allí. Si tiene contraseñas de hash, olvídese de MD5, incluso si lo encontró usado en una de las millones de aplicaciones PHP dañadas que hay. Para codificar las contraseñas, use PBKDF2 , bcrypt o scrypt . Si está pensando en usar algo que no sea uno de estos tres, lea ¿Cómo codificar de forma segura las contraseñas? primero, todas ellas.

Para un hash de contraseña, la idea de agregar un componente secreto a la función hash se denomina pimienta . Un pimiento involucra una clave secreta y algo de criptografía real: "cambiar algunos caracteres" sería tan fácil de revertir que es inútil como un pimiento. La forma normal de incluir un pimiento es agregarlo a la contraseña y a la sal al calcular el hash. Y recuerde que la pimienta debe ser secreta: si está en el origen de su aplicación, o en la misma base de datos o en los mismos discos de respaldo que la base de datos de contraseñas, es inútil.

El problema que intenta resolver es que los usuarios manipulan los valores de los campos de formulario ocultos.

Como dijo @Gilles, estos valores deben controlarse en la sesión (lado del servidor). Las verificaciones del lado del servidor son necesarias para verificar que el usuario dado tenga permiso para cambiar una publicación determinada. En otras palabras, el campo oculto "user_id" no debería existir! El valor de la ID de usuario se conocerá en la sesión.