Ver la Versión Completa : [MySQL] Funciones de encriptación MySql
Josber
3 de junio de 2015, 12:21
¿ Alguien ha utilizado éstas funciones ?.
He estado haciendo pruebas y la encriptación bien, pero la desencriptación siempre me devuelve NULL
por ejemplo:
select aes_encrypt('hola mundo','hola')
me devuelve "7ebc5af2638fab23d0828131db36c6c1"
pero al desencriptar, me devuelve "NULL"
He probado con varias funciones de encriptación y siempre es igual.
Muchas gracias
Un saludo.-
Kuk
3 de junio de 2015, 17:30
Josber, que yo sepa, los valores encriptados nunca se desencriptan. Lo que se suele hacer, es tambien encriptar el valor nuevo y comprarlos. Es decir, un tío se da de alta como usuario, su contraseña se encripta y se guarda en la tabla. Cada vez que el tío accede a su cuenta, NO se desencripta su contraseña nunca. Se encripta la que viene de introducir y se compara con la guardada (ya encriptada).
Este es (que yo sepa) el modus operandi de las encriptaciones en MySQL. ;)
Josber
3 de junio de 2015, 19:11
Necesito desencriptarlos Kuk, es una tabla que guarda datos "sensibles", que han de ser encriptados, para más tarde, desencriptarlos y mostrarlos en un listview. Que siempre puede llegar un "listillo", abrir la tabla con un gestor de SQL, como el XAMP/WAMP, y ver los datos, o lo que es peor modifcarlos
Un saludo.-
Añadido despues de 13 minutos
Mira, te pongo las dos maneras que he usado:
En ésta me devuelve un valor NULL en LPPRO1...LPPRO5
EXEC SQL
DECLARE cursor_tabla CURSOR FOR
SELECT LPNUM,
AES_DECRYPT(LPPRO1,'FaCtUrAcIóN'),
AES_DECRYPT(LPPRO2,'FaCtUrAcIóN'),
AES_DECRYPT(LPPRO3,'FaCtUrAcIóN'),
AES_DECRYPT(LPPRO4,'FaCtUrAcIóN'),
AES_DECRYPT(LPPRO5,'FaCtUrAcIóN'),
AES_DECRYPT(LPPRO6,'FaCtUrAcIóN')
FROM LPRO
END-EXEC.
.
.
.
EXEC SQL
FETCH cursor_tabla
INTO :LPNUM,
:LPPRO1,
:LPPRO2,
:LPPRO3,
:LPPRO4,
:LPPRO5,
:LPPRO6
Y ésta otra, me dice que faltan las variables depués del INTO
EXEC SQL
DECLARE cursor_tabla CURSOR FOR
SELECT LPNUM,
LPPRO1,
LPPRO2,
LPPRO3,
LPPRO4,
LPPRO5,
LPPRO6
FROM LPRO
END-EXEC.
.
.
.
EXEC SQL
FETCH cursor_tabla
INTO :LPNUM
AES_DECRYPT(:LPPRO1,'FaCtUrAcIóN'),
AES_DECRYPT(:LPPRO2,'FaCtUrAcIóN'),
AES_DECRYPT(:LPPRO3,'FaCtUrAcIóN'),
AES_DECRYPT(:LPPRO4,'FaCtUrAcIóN'),
AES_DECRYPT(:LPPRO5,'FaCtUrAcIóN'),
AES_DECRYPT(:LPPRO6,'FaCtUrAcIóN')
END-EXEC.
Un saludo.-
Kuk
3 de junio de 2015, 19:56
Josber, en el segundo te falta una coma:
EXEC SQL
FETCH cursor_tabla
INTO :LPNUM /* <== AQUI!!! */
AES_DECRYPT(:LPPRO1,'FaCtUrAcIóN'),
AES_DECRYPT(:LPPRO2,'FaCtUrAcIóN'),
AES_DECRYPT(:LPPRO3,'FaCtUrAcIóN'),
AES_DECRYPT(:LPPRO4,'FaCtUrAcIóN'),
AES_DECRYPT(:LPPRO5,'FaCtUrAcIóN'),
AES_DECRYPT(:LPPRO6,'FaCtUrAcIóN')
END-EXEC.
En cuanto a lo de NULL, haces todo bien. El problema es (según he leído), la longitud de los campos encriptados. Es decir, si usas VarChar, debes saber la longitud exacta e indicarsela a la hora de decriptar. Si algo no le cuadra, devuelve NULL:
The answer is that the columns are binary when they should be varbinary. This article explains it:
Because if AES_DECRYPT() detects invalid data or incorrect padding, it will return NULL.
With binary column types being fixed length, the length of the input value must be known to ensure correct padding. For unknown length values, use varbinary to avoid issues with incorrect padding resulting from differing value lengths.
Para indicar la longitud, graba todo con la misma longitud y haz SELECT indicando esa misma longitud. Cómo se declaraban los VarChar en COBOL creo que te lo comenté. Si no te acuerdas, te lo pongo otra vez.
Si no tienes datos muy largos, usa Char ;)
Josber
3 de junio de 2015, 20:13
Pues mañana probaré Kuk, lo de la coma, es que al pasarlo me la he comido, pero está puesta.
Y sí, creo que lo tengo, es lo del LEVEL 49, ¿no?
Un saludo
Kuk
3 de junio de 2015, 22:58
es lo del LEVEL 49, ¿no?
Eso es! Ya me contarás qué tal ;)
01 MI-VARCHAR.
49 MI-VARCHAR-L PIC S9(9) COMP-4.
49 MI-VARCHAR-D PIC X(nn).
Josber
4 de junio de 2015, 13:12
Nada no hay manera, ahora con esa definición de las variables, cuando el programa "entra" en la sentencia SQL de grabar, se queda en el limbo y no hace nada ...
Un saludo
Kuk
4 de junio de 2015, 14:43
Josber, puede que haya problemas con los VarChar, intenta con los Char de longitud fija y a ver qué tal. Es decir, definir los campos como Char en lugar de VarChar, definir variables de la misma longitud e intentar así.
También te digo que yo lo que hice un día fue encriptarlos por programa, me hice 2 rutinas correspondientes a encriptado y decriptado, directmanete en COBOL, en el própio módulo. Escribía en un fichero, y abriendolo en UltraEdit, solo se veía cilandro en vez de texto :D Decriptar eso no hay manera como tal, ahí hay que decompilar el programa y ver qué es lo que hace, cosa que ya hablamos de hackers Senior Executive :D Profesionales de semejante calibre no se van a molestar con programas como el tuyo o el mío ;)
Juanghi
12 de julio de 2015, 02:06
Al encriptar una clave por ejemplo, le adjuntas una palabra que te pueda descencriptar
eje tipico .. una tabla de usuarios
INSERT INTO usuarios
(cod_usu, cla_usu, nom_usu)
VALUES ('codigousu', AES_ENCRYPT('clave', 'secreta'), 'nombre usuario')
.. donde secretar es la palaba que usuaras para saber la clave
.. luego en
SELECT
cod_usu, AES_DECRYPT(cla_usu, 'secreta') AS cla_usu, nom_usu
cod_usu, cla_usu, nom_usu
FROM usuarios WHERE cod_usu = 'codigousu'
te rescatara el registro con la clave abierta .. en este caso = a 'clave'
vBulletin v3.8.7, Derechos ©2000-2026, Jelsoft Enterprises Ltd.