Verificar la manipulación de la base de datos

¿Por qué un salt ?

En mi mente, una sal es una pequeña adición para hacer más sabor. Normalmente, la sal se almacena en la misma base de datos que el propio valor hash.

Agregar un salt no agregará seguridad y no minimizará la posibilidad de colisión. En todo caso, si las colisiones son posibles, ¡simplemente se moverán ! ¡No creas que puedes compensar el mal método de hash agregando sal!

Si combina los primeros 3 campos con un secret phrase , podrá realizar la verificación. Pero la posibilidad de obtener colisiones está claramente relacionada con el número de filas. Si su objetivo es hacerle difícil a un pirata informático para crear el hash adecuado, debe utilizar una frase secreta . ¡Sobre todo si estás esperando muchas filas en tu base de datos!

Más de su base de datos es grande, más fácil de descifrar con fuerza bruta . ¡Así que preocuparse por el método hash!

Otras formas

Usando la función del servidor, como mysql binlogs para informar cada operación en un servidor de respaldo seguro (podría ser un NAS en solo escritura ).

Una forma más sencilla podría ser hacer copias de seguridad diferenciales de diferenciales y observar los paquetes de transacciones de diff (el procedimiento de copia de seguridad podría activarse muy de cerca si toda la base de datos puede permanecer en la memoria RAM).

O finalmente, podría agregar disparadores al motor de base de datos para que se le avise a y esté atento a las alteraciones en los archivos de la base de datos, utilizando herramientas del sistema como FAM ou Inotify .

Además de usar HMAC para verificar la integridad de las filas, use el sistema de permisos de DB para evitar la ACTUALIZACIÓN y ELIMINACIÓN de filas en esta tabla / db. Permitir solo INSERTAR y SELECCIONAR.

El almacenamiento de los hashes en la misma tabla que los datos solo permite que un pirata informático vea que tiene un mecanismo de manipulación indebida. Si un atacante obtiene acceso a la información de la tabla, es probable que descubran que está pasando algo y que actúen en consecuencia. El uso de hashes no es una mala idea, sin embargo, debe almacenarlos en una base de datos separada en un sistema separado, ya que no tiene sentido divulgar información. En cuanto a la sal (más de una clave realmente), no estoy seguro de lo que tenía en mente, pero creo que es una buena idea, ya que si tiene los hashes en una base de datos separada, la sal es otra capa de protección contra manipulación indebida: si el atacante sí detecta que tienes una base de datos de hashes que todavía tendrán que averiguar qué es la sal (IV, clave, lo que sea).

No has mencionado de quién estás protegiendo tu base de datos y qué capacidades tienen. Si su plan de hash es adecuado depende del nivel de acceso del atacante.

1. El atacante tiene una cuenta "normal" en la base de datos . Esto podría ser a través de una inyección SQL. La sugerencia de @ Matrix de solo permitir los privilegios INSERT y SELECT funciona bien en este caso, aunque sí significa que su aplicación no puede BORRAR o ACTUALIZAR o REEMPLAZAR o TRUNCAR o SALTAR o ALTERAR o muchos otros comandos.
2. El atacante tiene una cuenta de superusuario en la base de datos . Dado que el atacante ahora tiene privilegios de ACTUALIZACIÓN, el secreto de su algoritmo / clave / sal es lo único que le impide recalcular el hash cuando cambia los otros valores. Obviamente, esto significa que las claves no pueden almacenarse en la base de datos. Se pueden almacenar en una base de datos diferente o en el servidor de aplicaciones.
3. El atacante tiene una cuenta de shell en su servidor de aplicaciones . Esto podría ocurrir a través de una vulnerabilidad de inyección de código en su aplicación. En este caso, la clave secreta o la sal o el algoritmo ya no son secretos. Él tiene acceso al código de su aplicación y dondequiera que se puedan almacenar las claves secretas, la aplicación debe poder acceder a ellas, de modo que el atacante también podrá hacerlo.

La forma en que lograría su objetivo es enviar inmediatamente un registro de todos los cambios desde la base de datos a un servidor de registro dedicado. Si estamos hablando de MySQL, configurar un servidor de replicación hará el trabajo. El subproceso SQL no necesita ejecutarse en el esclavo porque los archivos de registro de retransmisión son su registro de todos los cambios. Los registros binarios de MySQL son un registro de todas las consultas de escritura a una base de datos. Puede ver el contenido de un registro binario de MySQL (o registro de retransmisión, que es lo que se llama una vez que un esclavo lo ha transferido desde el maestro) con el comando mysqlbinlog .

Su servidor de registro debe estar bien protegido. Idealmente, debería tener el número mínimo de cuentas de usuario posibles y cualquier cuenta de usuario debería tener una contraseña o clave SSH diferente al resto de sus servidores.

Este esquema tiene la ventaja de que no solo puede detectar que se ha realizado un cambio, sino que también puede mirar más atrás en los registros para averiguar cuáles eran los valores antes de que se realizara el cambio. Puede ser superado por un atacante que logra adquirir una cuenta de shell raíz en el servidor de base de datos principal.