Alternativa adecuada a CryptEncrypt

Question

Tenemos una situación en nuestro producto en la que durante mucho tiempo algunos datos se han almacenado en la base de datos de la aplicación como una cadena SQL (elección de servidor MS SQL o Sybase SQL en cualquier lugar) que se cifró a través de la función API de Windows. CriptaCifrar. (directo y descifrable)

El problema es que CryptEncrypt puede producir NULL en la salida, lo que significa que cuando se almacena en la base de datos, las manipulaciones de cadenas en algún momento truncarán el CipherText.

Idealmente, nos gustaría usar un algoritmo que produzca CipherText que no contenga NULL, ya que eso causará la menor cantidad de cambios en las bases de datos existentes (cambiar una columna de cadena a binaria y el código para tratar con binarios en lugar de cadenas). y simplemente descifre los datos existentes y vuelva a cifrarlos con el nuevo algoritmo en el momento de la actualización de la base de datos.

No es necesario que el algoritmo sea el más seguro, ya que la base de datos ya se encuentra en un entorno razonablemente seguro (no una red abierta/interwebs), pero sí debe ser mejor que ROT13 (que casi puedo descifrar en mi cabeza). ¡ahora!)

editar:Por cierto, ¿alguna razón particular para cambiar el texto cifrado por texto cifrado?El texto cifrado parece más utilizado...

Answer 1

Cualquier algoritmo semi-decente terminará con una gran posibilidad de generar un valor NULL en algún lugar del texto cifrado resultante.

¿Por qué no hacer algo como codificación base-64 ¿Su blob binario resultante antes de persistir en la base de datos?(implementación de muestra en C++).

Answer 2

Almacenar un hash es una buena idea.Sin embargo, definitivamente lea el artículo de Jeff. Probablemente estés almacenando contraseñas incorrectamente.

Answer 3

Esa es una ruta interesante OJ.Estamos analizando la viabilidad de un método no reversible (aún asegurándonos de no recuperar explícitamente los datos para descifrarlos), por ejemplo.simplemente almacene un Hash para comparar en un envío

Answer 4

Parece que el desarrollador que maneja esto va a envolver el cifrado existente con yEnc para preservar la integridad de la tabla ya que los datos deben ser recuperables, y esto ahorra todo ese desorden con infinita improbab...uhhh cambiando tipos de columnas en instalaciones arraigadas.Animo amigos