In order for this site to work correctly we need to store a small file (called a cookie) on your computer. Most every site in the world does this, however since the 25th of May 2011, by law we have to get your permission first. Please abandon the forum if you disagree.
Para que este foro funcione correctamente es necesario guardar un pequeño fichero (llamado cookie) en su ordenador. La mayoría de los sitios de Internet lo hacen, no obstante desde el 25 de Marzo de 2011 y por ley, necesitamos de su permiso con antelación. Abandone este foro si no está conforme.
Para que este foro funcione correctamente es necesario guardar un pequeño fichero (llamado cookie) en su ordenador. La mayoría de los sitios de Internet lo hacen, no obstante desde el 25 de Marzo de 2011 y por ley, necesitamos de su permiso con antelación. Abandone este foro si no está conforme.
Resultados erróneos con XA_Aes256Encrypt y XA_Aes256Decrypt
-
- Mensajes: 420
- Registrado: Sab Ago 16, 2008 9:06 pm
Resultados erróneos con XA_Aes256Encrypt y XA_Aes256Decrypt
Hola
Adjunto un ejempo de resultados erróneos usando XA_Aes256Encrypt y
XA_Aes256Decrypt.
Con el ejemplo de prueba funciona correctamente, pero al cambiar el
valor a encriptar por otra cosa, unas veces funciona bien y otras no.
Saludos
Alf+.
--
Adjunto un ejempo de resultados erróneos usando XA_Aes256Encrypt y
XA_Aes256Decrypt.
Con el ejemplo de prueba funciona correctamente, pero al cambiar el
valor a encriptar por otra cosa, unas veces funciona bien y otras no.
Saludos
Alf+.
--
Resultados erróneos con XA_Aes256Encrypt y XA_Aes256Decrypt
José Alfonso,
> Adjunto un ejempo de resultados erróneos usando XA_Aes256Encrypt y
> XA_Aes256Decrypt.
>
> Con el ejemplo de prueba funciona correctamente, pero al cambiar el
> valor a encriptar por otra cosa, unas veces funciona bien y otras no.
Es por el tamaño del texto a encriptar. El algoritmo AES trabaja siempre
en bloques de 16 bytes, tanto para el texto a cifrar como para la clave.
En el caso de la clave, Xailer se encarga de agrandarla lo que sea
necesario para llegar a un múltiplo de 16 bytes, pero el texto a cifrar no.
No obstante, veo que no estaba indicado en la ayuda. Vamos a corregirla.
Un saludo,
José F. Giménez
> Adjunto un ejempo de resultados erróneos usando XA_Aes256Encrypt y
> XA_Aes256Decrypt.
>
> Con el ejemplo de prueba funciona correctamente, pero al cambiar el
> valor a encriptar por otra cosa, unas veces funciona bien y otras no.
Es por el tamaño del texto a encriptar. El algoritmo AES trabaja siempre
en bloques de 16 bytes, tanto para el texto a cifrar como para la clave.
En el caso de la clave, Xailer se encarga de agrandarla lo que sea
necesario para llegar a un múltiplo de 16 bytes, pero el texto a cifrar no.
No obstante, veo que no estaba indicado en la ayuda. Vamos a corregirla.
Un saludo,
José F. Giménez
-
- Mensajes: 420
- Registrado: Sab Ago 16, 2008 9:06 pm
Resultados erróneos con XA_Aes256Encrypt y XA_Aes256Decrypt
Ok. Lo tengo en cuenta.
Gracias
Saludos
Alf+.
El 27/12/2012 12:24, Jose F. Gimenez escribió:
> José Alfonso,
>
>> Adjunto un ejempo de resultados erróneos usando XA_Aes256Encrypt y
>> XA_Aes256Decrypt.
>>
>> Con el ejemplo de prueba funciona correctamente, pero al cambiar el
>> valor a encriptar por otra cosa, unas veces funciona bien y otras no.
>
> Es por el tamaño del texto a encriptar. El algoritmo AES trabaja siempre
> en bloques de 16 bytes, tanto para el texto a cifrar como para la clave.
> En el caso de la clave, Xailer se encarga de agrandarla lo que sea
> necesario para llegar a un múltiplo de 16 bytes, pero el texto a cifrar no.
>
> No obstante, veo que no estaba indicado en la ayuda. Vamos a corregirla.
>
>
> Un saludo,
>
> José F. Giménez
Gracias
Saludos
Alf+.
El 27/12/2012 12:24, Jose F. Gimenez escribió:
> José Alfonso,
>
>> Adjunto un ejempo de resultados erróneos usando XA_Aes256Encrypt y
>> XA_Aes256Decrypt.
>>
>> Con el ejemplo de prueba funciona correctamente, pero al cambiar el
>> valor a encriptar por otra cosa, unas veces funciona bien y otras no.
>
> Es por el tamaño del texto a encriptar. El algoritmo AES trabaja siempre
> en bloques de 16 bytes, tanto para el texto a cifrar como para la clave.
> En el caso de la clave, Xailer se encarga de agrandarla lo que sea
> necesario para llegar a un múltiplo de 16 bytes, pero el texto a cifrar no.
>
> No obstante, veo que no estaba indicado en la ayuda. Vamos a corregirla.
>
>
> Un saludo,
>
> José F. Giménez
Resultados erróneos con XA_Aes256Encrypt y XA_Aes256Decrypt
Quiero probar eso de "encriptar" los datos...
Y me surgen dudas, como es normal.
¿Que haceis con el "sobrante" del texto a procesar, ya que como decis, debe
ser un múltiplo de 16.?
¿Lo dejais tal cual?
¿El texto de la cadena encriptada SIEMPRE tendrá la misma longitud que el
texto a encriptar?
¿Hay funciones alternativas de Harbour para encriptar texto sin necesidad de
ser múltiplo de nada?
Un Saludo,
Xevi.
"José Alfonso Suárez Moreno" ha escrit al
missatge:50dc9d1e$[email=2@svctag-j7w3v3j....]2@svctag-j7w3v3j....[/email]
Ok. Lo tengo en cuenta.
Gracias
Saludos
Alf+.
El 27/12/2012 12:24, Jose F. Gimenez escribió:
> José Alfonso,
>
>> Adjunto un ejempo de resultados erróneos usando XA_Aes256Encrypt y
>> XA_Aes256Decrypt.
>>
>> Con el ejemplo de prueba funciona correctamente, pero al cambiar el
>> valor a encriptar por otra cosa, unas veces funciona bien y otras no.
>
> Es por el tamaño del texto a encriptar. El algoritmo AES trabaja siempre
> en bloques de 16 bytes, tanto para el texto a cifrar como para la clave.
> En el caso de la clave, Xailer se encarga de agrandarla lo que sea
> necesario para llegar a un múltiplo de 16 bytes, pero el texto a cifrar
> no.
>
> No obstante, veo que no estaba indicado en la ayuda. Vamos a corregirla.
>
>
> Un saludo,
>
> José F. Giménez
Y me surgen dudas, como es normal.
¿Que haceis con el "sobrante" del texto a procesar, ya que como decis, debe
ser un múltiplo de 16.?
¿Lo dejais tal cual?
¿El texto de la cadena encriptada SIEMPRE tendrá la misma longitud que el
texto a encriptar?
¿Hay funciones alternativas de Harbour para encriptar texto sin necesidad de
ser múltiplo de nada?
Un Saludo,
Xevi.
"José Alfonso Suárez Moreno" ha escrit al
missatge:50dc9d1e$[email=2@svctag-j7w3v3j....]2@svctag-j7w3v3j....[/email]
Ok. Lo tengo en cuenta.
Gracias
Saludos
Alf+.
El 27/12/2012 12:24, Jose F. Gimenez escribió:
> José Alfonso,
>
>> Adjunto un ejempo de resultados erróneos usando XA_Aes256Encrypt y
>> XA_Aes256Decrypt.
>>
>> Con el ejemplo de prueba funciona correctamente, pero al cambiar el
>> valor a encriptar por otra cosa, unas veces funciona bien y otras no.
>
> Es por el tamaño del texto a encriptar. El algoritmo AES trabaja siempre
> en bloques de 16 bytes, tanto para el texto a cifrar como para la clave.
> En el caso de la clave, Xailer se encarga de agrandarla lo que sea
> necesario para llegar a un múltiplo de 16 bytes, pero el texto a cifrar
> no.
>
> No obstante, veo que no estaba indicado en la ayuda. Vamos a corregirla.
>
>
> Un saludo,
>
> José F. Giménez
Un Saludo,
Xevi.
Xevi.
Resultados erróneos con XA_Aes256Encrypt y XA_Aes256Decrypt
Xevi,
> Quiero probar eso de "encriptar" los datos...
> Y me surgen dudas, como es normal.
>
> ¿Que haceis con el "sobrante" del texto a procesar, ya que como decis,
> debe ser un múltiplo de 16.?
> ¿Lo dejais tal cual?
> ¿El texto de la cadena encriptada SIEMPRE tendrá la misma longitud que
> el texto a encriptar?
El algoritmo AES exige que siempre se cifren los datos en bloques de 16
bytes, y la clave debe de tener siempre 32 bytes. Y como decía aquel:
"esto no es negociable". Vamos, que esto es así porque es como funciona
el algoritmo. No hay otra opción.
Dicho esto, cuando se llama a las funciones de AES, Xailer expande la
clave que le pasas a 32 bytes en total, simplemente repitiéndola una y
otra vez hasta completar los 32 bytes. P.ej., si usas la clave "1234",
entonces Xailer la expandirá a "123412341234....1234".
Respecto a la cadena a cifrar, Xailer prepara un buffer de salida que es
mútiplo de 16 bytes, pero actualmente no comprueba el tamaño del buffer
de entrada, y eso es lo que da pie a errores en los procesos de crifrado
y descifrado de datos. Por eso es tan importante que la cadena siempre
sea mútiplo de 16 bytes. Pero esto es tan sencillo como hacer un Pad()
previamente.
> ¿Hay funciones alternativas de Harbour para encriptar texto sin
> necesidad de ser múltiplo de nada?
La verdad es que no lo sé, pero sí te puedo asegurar que todos los
algoritmos de cifrado simétrico más o menos serios, son de cifrado por
bloques (http://es.wikipedia.org/wiki/Cifrado_por_bloques).
Un saludo,
José F. Giménez
http://www.xailer.com
http://www.xailer.info
> Quiero probar eso de "encriptar" los datos...
> Y me surgen dudas, como es normal.
>
> ¿Que haceis con el "sobrante" del texto a procesar, ya que como decis,
> debe ser un múltiplo de 16.?
> ¿Lo dejais tal cual?
> ¿El texto de la cadena encriptada SIEMPRE tendrá la misma longitud que
> el texto a encriptar?
El algoritmo AES exige que siempre se cifren los datos en bloques de 16
bytes, y la clave debe de tener siempre 32 bytes. Y como decía aquel:
"esto no es negociable". Vamos, que esto es así porque es como funciona
el algoritmo. No hay otra opción.
Dicho esto, cuando se llama a las funciones de AES, Xailer expande la
clave que le pasas a 32 bytes en total, simplemente repitiéndola una y
otra vez hasta completar los 32 bytes. P.ej., si usas la clave "1234",
entonces Xailer la expandirá a "123412341234....1234".
Respecto a la cadena a cifrar, Xailer prepara un buffer de salida que es
mútiplo de 16 bytes, pero actualmente no comprueba el tamaño del buffer
de entrada, y eso es lo que da pie a errores en los procesos de crifrado
y descifrado de datos. Por eso es tan importante que la cadena siempre
sea mútiplo de 16 bytes. Pero esto es tan sencillo como hacer un Pad()
previamente.
> ¿Hay funciones alternativas de Harbour para encriptar texto sin
> necesidad de ser múltiplo de nada?
La verdad es que no lo sé, pero sí te puedo asegurar que todos los
algoritmos de cifrado simétrico más o menos serios, son de cifrado por
bloques (http://es.wikipedia.org/wiki/Cifrado_por_bloques).
Un saludo,
José F. Giménez
http://www.xailer.com
http://www.xailer.info
Resultados erróneos con XA_Aes256Encrypt y XA_Aes256Decrypt
Jose,
muchas gracias.
Me queda una duda en el tintero...
> ¿El texto de la cadena encriptada SIEMPRE tendrá la misma longitud que el
> texto a encriptar?
o sea... si encripto un texto de un campo que ocupa 25 caracteres en una
DBF, el texto encriptado, ¿cuanto ocupará?
Lo digo por si se respeta el ancho de los campos dados en una estructura de
una DBF o como hay que hacerlo.
Un Saludo,
Xevi.
"Jose F. Gimenez" ha escrit al missatge:5195e9f0$[email=1@svctag-j7w3v3j....]1@svctag-j7w3v3j....[/email]
Xevi,
> Quiero probar eso de "encriptar" los datos...
> Y me surgen dudas, como es normal.
>
> ¿Que haceis con el "sobrante" del texto a procesar, ya que como decis,
> debe ser un múltiplo de 16.?
> ¿Lo dejais tal cual?
> ¿El texto de la cadena encriptada SIEMPRE tendrá la misma longitud que el
> texto a encriptar?
El algoritmo AES exige que siempre se cifren los datos en bloques de 16
bytes, y la clave debe de tener siempre 32 bytes. Y como decía aquel:
"esto no es negociable". Vamos, que esto es así porque es como funciona
el algoritmo. No hay otra opción.
Dicho esto, cuando se llama a las funciones de AES, Xailer expande la
clave que le pasas a 32 bytes en total, simplemente repitiéndola una y
otra vez hasta completar los 32 bytes. P.ej., si usas la clave "1234",
entonces Xailer la expandirá a "123412341234....1234".
Respecto a la cadena a cifrar, Xailer prepara un buffer de salida que es
mútiplo de 16 bytes, pero actualmente no comprueba el tamaño del buffer
de entrada, y eso es lo que da pie a errores en los procesos de crifrado
y descifrado de datos. Por eso es tan importante que la cadena siempre
sea mútiplo de 16 bytes. Pero esto es tan sencillo como hacer un Pad()
previamente.
> ¿Hay funciones alternativas de Harbour para encriptar texto sin necesidad
> de ser múltiplo de nada?
La verdad es que no lo sé, pero sí te puedo asegurar que todos los
algoritmos de cifrado simétrico más o menos serios, son de cifrado por
bloques (http://es.wikipedia.org/wiki/Cifrado_por_bloques).
Un saludo,
José F. Giménez
http://www.xailer.com
http://www.xailer.info
muchas gracias.
Me queda una duda en el tintero...
> ¿El texto de la cadena encriptada SIEMPRE tendrá la misma longitud que el
> texto a encriptar?
o sea... si encripto un texto de un campo que ocupa 25 caracteres en una
DBF, el texto encriptado, ¿cuanto ocupará?
Lo digo por si se respeta el ancho de los campos dados en una estructura de
una DBF o como hay que hacerlo.
Un Saludo,
Xevi.
"Jose F. Gimenez" ha escrit al missatge:5195e9f0$[email=1@svctag-j7w3v3j....]1@svctag-j7w3v3j....[/email]
Xevi,
> Quiero probar eso de "encriptar" los datos...
> Y me surgen dudas, como es normal.
>
> ¿Que haceis con el "sobrante" del texto a procesar, ya que como decis,
> debe ser un múltiplo de 16.?
> ¿Lo dejais tal cual?
> ¿El texto de la cadena encriptada SIEMPRE tendrá la misma longitud que el
> texto a encriptar?
El algoritmo AES exige que siempre se cifren los datos en bloques de 16
bytes, y la clave debe de tener siempre 32 bytes. Y como decía aquel:
"esto no es negociable". Vamos, que esto es así porque es como funciona
el algoritmo. No hay otra opción.
Dicho esto, cuando se llama a las funciones de AES, Xailer expande la
clave que le pasas a 32 bytes en total, simplemente repitiéndola una y
otra vez hasta completar los 32 bytes. P.ej., si usas la clave "1234",
entonces Xailer la expandirá a "123412341234....1234".
Respecto a la cadena a cifrar, Xailer prepara un buffer de salida que es
mútiplo de 16 bytes, pero actualmente no comprueba el tamaño del buffer
de entrada, y eso es lo que da pie a errores en los procesos de crifrado
y descifrado de datos. Por eso es tan importante que la cadena siempre
sea mútiplo de 16 bytes. Pero esto es tan sencillo como hacer un Pad()
previamente.
> ¿Hay funciones alternativas de Harbour para encriptar texto sin necesidad
> de ser múltiplo de nada?
La verdad es que no lo sé, pero sí te puedo asegurar que todos los
algoritmos de cifrado simétrico más o menos serios, son de cifrado por
bloques (http://es.wikipedia.org/wiki/Cifrado_por_bloques).
Un saludo,
José F. Giménez
http://www.xailer.com
http://www.xailer.info
Un Saludo,
Xevi.
Xevi.
Resultados erróneos con XA_Aes256Encrypt y XA_Aes256Decrypt
Xevi,
> Me queda una duda en el tintero...
>> ¿El texto de la cadena encriptada SIEMPRE tendrá la misma longitud
>> que el texto a encriptar?
>
> o sea... si encripto un texto de un campo que ocupa 25 caracteres en
> una DBF, el texto encriptado, ¿cuanto ocupará?
> Lo digo por si se respeta el ancho de los campos dados en una
> estructura de una DBF o como hay que hacerlo.
No. Para cifrar 25 caracteres, tienes que expandir la cadena a 32
caracteres, con Pad( cCadena, 32 ), y el texto cifrado va a ocupar 32
caracteres. No intentes después recortarlo porque entonces no se puede
descifrar.
Si lo que vas a hacer es cifrar un campo que contiene una contraseña, lo
mejor que puedes hacer es establecer ese campo de 32, o mejor de 64,
caracteres, y guardar siempre la cadena convertida a hexadecimal. P.ej.:
REPLACE clave WITH StringToHex( cClaveCifrada )
Ten en cuenta que el texto en hexadecimal ocupa siempre justo el doble
que la cadena original. Si la cadena es de 16 caracteres, el resultado
será de 32, y si era de 32, el resultado será de 64 caracteres.
Y ya que estamos... para guardar contraseñas no hace falta usar un
algoritmo de cifrado simétrico, como AES. Se puede usar también un hash
de tipo MD5 (actualmente desaconsejable) o SHA1. La técnica consiste
siempre en no descifrar nunca las contraseñas guardadas. Lo que se hace
es que cuando el usuario escribe su contraseña para entrar, el texto que
ha escrito se vuelve a cifrar, y se compara con lo que tienes almacenado
en la BD. Esto es más seguro que utilizar AES o similares, porque de
algún modo tienes que usar una contraseña de cifrado que se podría
averiguar.
Un saludo,
José F. Giménez
http://www.xailer.com
http://www.xailer.info
> Me queda una duda en el tintero...
>> ¿El texto de la cadena encriptada SIEMPRE tendrá la misma longitud
>> que el texto a encriptar?
>
> o sea... si encripto un texto de un campo que ocupa 25 caracteres en
> una DBF, el texto encriptado, ¿cuanto ocupará?
> Lo digo por si se respeta el ancho de los campos dados en una
> estructura de una DBF o como hay que hacerlo.
No. Para cifrar 25 caracteres, tienes que expandir la cadena a 32
caracteres, con Pad( cCadena, 32 ), y el texto cifrado va a ocupar 32
caracteres. No intentes después recortarlo porque entonces no se puede
descifrar.
Si lo que vas a hacer es cifrar un campo que contiene una contraseña, lo
mejor que puedes hacer es establecer ese campo de 32, o mejor de 64,
caracteres, y guardar siempre la cadena convertida a hexadecimal. P.ej.:
REPLACE clave WITH StringToHex( cClaveCifrada )
Ten en cuenta que el texto en hexadecimal ocupa siempre justo el doble
que la cadena original. Si la cadena es de 16 caracteres, el resultado
será de 32, y si era de 32, el resultado será de 64 caracteres.
Y ya que estamos... para guardar contraseñas no hace falta usar un
algoritmo de cifrado simétrico, como AES. Se puede usar también un hash
de tipo MD5 (actualmente desaconsejable) o SHA1. La técnica consiste
siempre en no descifrar nunca las contraseñas guardadas. Lo que se hace
es que cuando el usuario escribe su contraseña para entrar, el texto que
ha escrito se vuelve a cifrar, y se compara con lo que tienes almacenado
en la BD. Esto es más seguro que utilizar AES o similares, porque de
algún modo tienes que usar una contraseña de cifrado que se podría
averiguar.
Un saludo,
José F. Giménez
http://www.xailer.com
http://www.xailer.info
Resultados erróneos con XA_Aes256Encrypt y XA_Aes256Decrypt
Jose,
Gracias, entiendo.
Tal como tengo mis DBFs no puedo encriptar campos, deberia de cambiar
tamaños... igual deberia de replantear la aplicación.
Para encriptar TODA una DBF, o un fichero... ¿alguna función?
Porque igual puedo encriptar toda la base de datos y que sea desde la
aplicación la encargada de "desencriptar" los datos i así poder trabajar y
visualizar los datos.
Un Saludo,
Xevi.
"Jose F. Gimenez" ha escrit al missatge:[email=5196213d@svctag-j7w3v3j....]5196213d@svctag-j7w3v3j....[/email]
Xevi,
> Me queda una duda en el tintero...
>> ¿El texto de la cadena encriptada SIEMPRE tendrá la misma longitud que el
>> texto a encriptar?
>
> o sea... si encripto un texto de un campo que ocupa 25 caracteres en una
> DBF, el texto encriptado, ¿cuanto ocupará?
> Lo digo por si se respeta el ancho de los campos dados en una estructura
> de una DBF o como hay que hacerlo.
No. Para cifrar 25 caracteres, tienes que expandir la cadena a 32
caracteres, con Pad( cCadena, 32 ), y el texto cifrado va a ocupar 32
caracteres. No intentes después recortarlo porque entonces no se puede
descifrar.
Si lo que vas a hacer es cifrar un campo que contiene una contraseña, lo
mejor que puedes hacer es establecer ese campo de 32, o mejor de 64,
caracteres, y guardar siempre la cadena convertida a hexadecimal. P.ej.:
REPLACE clave WITH StringToHex( cClaveCifrada )
Ten en cuenta que el texto en hexadecimal ocupa siempre justo el doble
que la cadena original. Si la cadena es de 16 caracteres, el resultado
será de 32, y si era de 32, el resultado será de 64 caracteres.
Y ya que estamos... para guardar contraseñas no hace falta usar un
algoritmo de cifrado simétrico, como AES. Se puede usar también un hash
de tipo MD5 (actualmente desaconsejable) o SHA1. La técnica consiste
siempre en no descifrar nunca las contraseñas guardadas. Lo que se hace
es que cuando el usuario escribe su contraseña para entrar, el texto que
ha escrito se vuelve a cifrar, y se compara con lo que tienes almacenado
en la BD. Esto es más seguro que utilizar AES o similares, porque de
algún modo tienes que usar una contraseña de cifrado que se podría
averiguar.
Un saludo,
José F. Giménez
http://www.xailer.com
http://www.xailer.info
Gracias, entiendo.
Tal como tengo mis DBFs no puedo encriptar campos, deberia de cambiar
tamaños... igual deberia de replantear la aplicación.
Para encriptar TODA una DBF, o un fichero... ¿alguna función?
Porque igual puedo encriptar toda la base de datos y que sea desde la
aplicación la encargada de "desencriptar" los datos i así poder trabajar y
visualizar los datos.
Un Saludo,
Xevi.
"Jose F. Gimenez" ha escrit al missatge:[email=5196213d@svctag-j7w3v3j....]5196213d@svctag-j7w3v3j....[/email]
Xevi,
> Me queda una duda en el tintero...
>> ¿El texto de la cadena encriptada SIEMPRE tendrá la misma longitud que el
>> texto a encriptar?
>
> o sea... si encripto un texto de un campo que ocupa 25 caracteres en una
> DBF, el texto encriptado, ¿cuanto ocupará?
> Lo digo por si se respeta el ancho de los campos dados en una estructura
> de una DBF o como hay que hacerlo.
No. Para cifrar 25 caracteres, tienes que expandir la cadena a 32
caracteres, con Pad( cCadena, 32 ), y el texto cifrado va a ocupar 32
caracteres. No intentes después recortarlo porque entonces no se puede
descifrar.
Si lo que vas a hacer es cifrar un campo que contiene una contraseña, lo
mejor que puedes hacer es establecer ese campo de 32, o mejor de 64,
caracteres, y guardar siempre la cadena convertida a hexadecimal. P.ej.:
REPLACE clave WITH StringToHex( cClaveCifrada )
Ten en cuenta que el texto en hexadecimal ocupa siempre justo el doble
que la cadena original. Si la cadena es de 16 caracteres, el resultado
será de 32, y si era de 32, el resultado será de 64 caracteres.
Y ya que estamos... para guardar contraseñas no hace falta usar un
algoritmo de cifrado simétrico, como AES. Se puede usar también un hash
de tipo MD5 (actualmente desaconsejable) o SHA1. La técnica consiste
siempre en no descifrar nunca las contraseñas guardadas. Lo que se hace
es que cuando el usuario escribe su contraseña para entrar, el texto que
ha escrito se vuelve a cifrar, y se compara con lo que tienes almacenado
en la BD. Esto es más seguro que utilizar AES o similares, porque de
algún modo tienes que usar una contraseña de cifrado que se podría
averiguar.
Un saludo,
José F. Giménez
http://www.xailer.com
http://www.xailer.info
Un Saludo,
Xevi.
Xevi.
Resultados erróneos con XA_Aes256Encrypt y XA_Aes256Decrypt
Xevi,
> Gracias, entiendo.
> Tal como tengo mis DBFs no puedo encriptar campos, deberia de cambiar
> tamaños... igual deberia de replantear la aplicación.
>
> Para encriptar TODA una DBF, o un fichero... ¿alguna función?
> Porque igual puedo encriptar toda la base de datos y que sea desde la
> aplicación la encargada de "desencriptar" los datos i así poder
> trabajar y visualizar los datos.
El datasource de SQLite implementa ya el cifrado completo de la BD, sin
necesidad de ningún software adicional. Es más, yo lo estoy usando, y
funciona perfectamente, te lo puedo asegurar. El fichero de la DB se
cifra completamente, incluida la cabecera, y es completamente
transparente para los datasets o para cualquier cosa que hagas desde
programa. Lo único que hay que hacer es asignar la propiedad cPassword
del datasource, y Xailer se encarga del resto
Pero para DBFs no tenemos nada. No sé si habrá algún RDD que lo haga,
pero a nivel del datasource de Xailer me temo que no.
Yo personalmente, aconsejo a todos los que utilizan DBFs a pasarse a
SQLite. Al ser un motor local, como los DBFs, el salto no es tan grande,
y sí que se obtienen los beneficios de usar SQL. Y si más adelante es
necesario, saltar a MySQL o MariaDB es muy sencillo, ya que SQLite es un
99% compatible con MySQL a nivel de dialecto SQL, mucho más compatible
que con cualquier otro motor o que otros motores entre sí. Yo mismo
tengo aplicaciones que funcionan tanto con SQLite como con MySQL/MariaDB
con sólo cambiar un parámetro en la configuración, y usando el mismo
código para todo. Tan sólo cambia el datasource.
Un saludo,
José F. Giménez
http://www.xailer.com
http://www.xailer.info
> Gracias, entiendo.
> Tal como tengo mis DBFs no puedo encriptar campos, deberia de cambiar
> tamaños... igual deberia de replantear la aplicación.
>
> Para encriptar TODA una DBF, o un fichero... ¿alguna función?
> Porque igual puedo encriptar toda la base de datos y que sea desde la
> aplicación la encargada de "desencriptar" los datos i así poder
> trabajar y visualizar los datos.
El datasource de SQLite implementa ya el cifrado completo de la BD, sin
necesidad de ningún software adicional. Es más, yo lo estoy usando, y
funciona perfectamente, te lo puedo asegurar. El fichero de la DB se
cifra completamente, incluida la cabecera, y es completamente
transparente para los datasets o para cualquier cosa que hagas desde
programa. Lo único que hay que hacer es asignar la propiedad cPassword
del datasource, y Xailer se encarga del resto
Pero para DBFs no tenemos nada. No sé si habrá algún RDD que lo haga,
pero a nivel del datasource de Xailer me temo que no.
Yo personalmente, aconsejo a todos los que utilizan DBFs a pasarse a
SQLite. Al ser un motor local, como los DBFs, el salto no es tan grande,
y sí que se obtienen los beneficios de usar SQL. Y si más adelante es
necesario, saltar a MySQL o MariaDB es muy sencillo, ya que SQLite es un
99% compatible con MySQL a nivel de dialecto SQL, mucho más compatible
que con cualquier otro motor o que otros motores entre sí. Yo mismo
tengo aplicaciones que funcionan tanto con SQLite como con MySQL/MariaDB
con sólo cambiar un parámetro en la configuración, y usando el mismo
código para todo. Tan sólo cambia el datasource.
Un saludo,
José F. Giménez
http://www.xailer.com
http://www.xailer.info