¿Alguna vez habéis mirado un ejecutable de gambas con un editor hexadecimal? Se puede ver que, como casi todos los generadores de P-Code, las cadenas de texto aparecen tal cual. Si, como yo, tenéis la mala costumbre de colocar de vez en cuando dentro del propio código las contraseñas y demás información de acceso a las bases de datos, veréis que es relativamente sencillo hacerse con ellas.
La manera de ocultar una cadena, la más sencilla al menos, es sustituirla por una serie de llamadas a la función CHR enviandole el valor numérico de la tabla ASCII de cada caracter. Es muy simple, pero un poco pesado de hacer.
Por eso he creado esta pequeña funcioncita, que dado un texto cualquiera te lo devuelve como una secuencia de llamadas a la función CHR con el valor ASCII de cada carácter. Solo tienes que copiar el resultado que te aparece en pantalla y sustituir en tu código fuente la cadena que no quieres que sea evidente.

La podéis encontrar aquí.

Espero que os sea de alguna utilidad.

Saludos

===================
No podemos regresar

Me parece que debería usarse el compente gb.crypt para ello. Si te lo pones a pensar, sustituir las cadenas por sus códigos ASCII no brinda ninguna seguridad. Alguien que tiene el conocimiento para mirar el P-Code con un editor hexadecimal, creo que tiene una alta probabilidad de ver el patrón en la secuencia de códigos ASCII o podría analizar el contenido de las cadenas con algún programa de criptografía que fácilmente pondría en evidencia las claves.

Mejor aún sería abandonar la mala costumbre de guardar contraseñas en el código.

Saludos cordiales.

===================
Cómo programar con Gambas

Speed Books: informática libre.

Pues no se me había ocurrido lo del gb.crypt..., vaya ceporro estoy hecho, siempre inventando la rueda y siempre ovalada.. jejeje.
Esto del chr es una vieja costumbre de los viejos tiempos de VBA.
De todas formas el tema de las contraseñas siempre ha sido un problema para mí:
Los usuarios no quieren tener que teclear ni nombres de servidores ni direcciones IP ni nombres de usuario de bases de datos ni nada de eso. Ya es un suplicio el oirlos quejarse de que tienen que poner la clave cuando encienden el ordenador, cuando actualizan, cuando entran en la aplicación, etc. etc.
Lo que hago es guardar todas las configuraciones globales (usuarios válidos, ámbito de cada uno, permisos sobre la base de datos, etc. etc.)en una base de datos independiente de la "base de datos de datos" (¡tóma experesión!).  Pero la contraseña de esa primera base de datos... ¿dónde guardarla si no es en el código?. Cualquier otro fichero externo a la aplicación es también vulnerable.
De ahí esa política, que no me gusta, pero que no veo modo de solucionar de otra manera de guardar, al menos una configuración de conexión en el propio codigo...
Se aceptan sugerencias.

De todas formas dejo la funcionceta colgada, por si a alguien le sirve de algo.

===================
No podemos regresar

Desde luego crypt (especialmente con md5) es la solución perfecta para almacenar unas claves, sin embargo no es la mejor solución para otras cosas de manera que estoy trabajando en la implemtación de RSA en gambas aunque actualmente estoy pillado con el algoritmo Miller-Rabin pero bueno je je ya lo solucionaré. El caso es que eso de meter cosas en código así como así es algo que debiera pensarse varias veces.

No cuesta nada hacer las cosas bien. Simplemente hay que preocuparse por estas cuestiones porque luego la función que te guarda un string ilegible puede tener cinco líneas si por ejemplo utilizas algún sistema elemental de traslación.

Por ejemplo: dado el alfabeto español y su correspondencia numérica en el código ascii basta hacer una pequeña función que devuelva un string encriptado de la siguiente forma

El primer caracter de resultado es la cantidad que se utilizó para trasladar. El resto es la cadena encriptada.

Así que desde ese momento basta con que cualquier string que no quieras que se vea por ningún lado hagas
string=EncriptarPorTraslacion(string) y ya está.

Para desencriptar habría que hacer lo contrario


Es decir para encriptar obtengo un valor aleatorio y a cada caracter le sumo ese valor. La string se encabeza con el valor aleatorio que utilizé para encriptar.
Para desencriptar cojo la string, obtengo el primer caracter y me quedo con su valor. A cada caracter del string le resto ese valor y obtengo el original.

Eso no engañará a la nsa pero si a un pardillo con un editor hexadecimal.

A mi esto de la criptografía es que me encanta aunque sean pequeñas bobaditas como esta. Todo es imaginar je je je. Por ejemplo en vez de guardar los caracteres encriptados seguidos puedo meter caracteres de morralla entre medias. Todo es imaginar.
 

Un tema muy interesante shordi
 

Esto que cuentas me recuerda una antigua encriptación que me hice hallá por los 80 (en los viejos tiempos del Clipper summer 87, na menos) para almacenar contraseñas en un fichero .DBF. En aquellas épocas esto de la encriptación no estaba al alcance de cualquiera, como ahora. Diseñé algo parecido a lo que cuentas, con cadenas de caracteres ASCII desplazados según un cálculo de la longitud de la cadena y entremezclados uno sí y otro no con ASCII aleatorio para despistar.
Molaba que te cagas cuando eseñabas la tabla a alguien y mencionabas la palabra "encriptado"... jejeje

Pero ahora no voy a tanto, lo gracioso es que las claves de los usuarios sí que las guardo con MD5 en la base de datos...
Ahora que caigo, Fabián ,¿MD5 no era un algoritmo de encriptación unidireccional? Creo recordar que sí... entonces no me vale para almacenar la contraseña en el código por que no puedo luego desencriptarla.  Necesito almacenarla "disimulada", pero accesible por el propio programa...

Un lío oiga.

(Po cierto Soplo, sobre criptografía te recomiendo "PopCo" una novelita bastante curiosa... y por supuesto la maravillosa exageración del  Cryptonomicon de Neil Stephenson... )

===================
No podemos regresar

ahí está

Citar:

Ahora que caigo, Fabián ,¿MD5 no era un algoritmo de encriptación unidireccional? Creo recordar que sí... entonces no me vale para almacenar la contraseña en el código por que no puedo luego desencriptarla. Necesito almacenarla "disimulada", pero accesible por el propio programa...

Md5 es bueno cuando tu quieres guardar una contraseña (que guardas encriptada para que un capullo con un editor hexadecimal no te la vea) y un usuario remoto al que se le pide una contraseña debe ser comprobada. En ese caso tu encriptas lo que el usuario envió y lo comparas con lo que tienes.

Pero si lo que quieres por ejemplo es poder enviarle a alguien una clave segura (por ejemplo a tí mismo) entonces necesitas acudir a sistemas de cifrado de de clave pública que es un sistema seguro de enviar una contraseña a otra parte (o a tí mismo) y luego están los sistemas de cifrado simétricos que permiten conociendo la clave cifrar o descrifrar un mensaje y esa es la razón por la que estoy trabajando en RSA. Porque MD5 y DES que trae gambas no son suficientes para diversas tareas. Hay un gran hueco allí que pretendo cubrir. Con RSA podré integrar SSH o PGP en las aplicaciones y tener la capacidad de enviar una clave de forma segura. Tras ello podré encriptar o desencriptar mensajes conociendo esa clave mediante 3DES, pero para eso necesito resolver correctamente el algoritmo de Miller-Rabin cosa que no consigo y que acabo de caer que puede ser diferente en 32 bits que en 64 bits.

Así que entiendo que en tu caso la forma segura de guardar una contraseña para tu aplicación sería guardarla dividida en varios sitios que combine tu aplicación.

La criptografía a mi me divierte. Es una forma divertida de devanarse los sesos je je je