No hay seguridad en las aplicaciones !!

[erickperez6]

Saludos !!!

Tengo una aplicacion en interbase, en donde el control de acceso de los usuarios a la aplicacion es mediante una tabla de usuarios creada por mi, la coneccion a la base de datos lo hago internamente desde la aplicacion poniendole el usuario y la clave al componente TIBDatabase (IBX). Bien, cuando edito el programa executable que me genera delphi con cualquier editor de texto, observo muchas sentencias del codigo fuente que utilizo y aparte de eso el usuario y la clave de la base de datos.

Pensaba que la compilacion a ejecutable tambien se llevaba los caracteres del codigo fuente a el mismo lenguaje de maquina, pero no es asi, la gran mayoria quedan intactos, pero lo que mas me preocupa es el usuario y la clave de la DB.

[kinobi]

Hola,

Posteado originalmente por erickperez6 Pensaba que la compilacion a ejecutable tambien se llevaba los caracteres del codigo fuente a el mismo lenguaje de maquina, pero no es asi, la gran mayoria quedan intactos, pero lo que mas me preocupa es el usuario y la clave de la DB.

el juego de caracteres que utilices para las cadenas de tu ejecutable Delphi no se modifica por la compilación. La cadena 'MiUsuario' o 'MiContraseña' será la misma en el fuente o en el binario.

Solución: encriptación.

Puede ser tan simple como implantar un pequeño algoritmo que te desplace los caracteres de la cadena unas posiciones o algoritmos más complejos.

Ejemplo:

Cadena original: 'IBM'.
Cadena desplazada una posición a la izquierda: 'HAL' (esta cadena sería la que introducirías en el código fuente, y sería lo que se vería también el binario).

A la hora de introducir la cadena (usuario y/o contraseña) en el componente TIBDatabase volverías a desplazar la cadena, pero esta vez un caracter a la derecha, para obtener la cadena original ('IBM').

Con esto consigues que en el binario no se vean las cadenas originales.

Evidentemente el ejemplo es muy sencillo, y alguien con conocimientos adecuados (desensamblado el binario) podría descifrar tu algoritmo de desencriptación y obtener el valor original a partir de la cadena encriptada ... pero menos es nada.

Saludos.

[marcoszorrilla]

Aparte de lo que te dice Kinobi, también se le suele añadir el efecto mareo, que se aconsejaba también en ensamblador.

Es decir para obtener la clave llamar a varias funciones que no hacen nada, pero que colocan valores en los registros y simulan operaciones de desplazamiento SHl - SHR .......

Codificar como quedó dicho por Kinobi y fragmentar la clave.

Quien intente descifrar la clave ante tanto mareo sino hay más que simple curiosidad por el medio, desistirá.

Un Saludo.

[vecino]

Hola:

También puedes usar un compresor de ejecutables como el UPX.

Acostumbro a usar estos programas cuando no quiero que vean o modifiquen las cadenas del ejecutable final.

Saludos.

[lbuelvas]

Hola amigos,

ese tipo de practica (que utilice por cerca de 3 años), el de colocar dentro de los componentes el nombre de usuario y password creo que no es recomendable no solo pro el problema de seguridad que se comenta sino ademas porque si a algun gracioso le da por cambiar el password del sysdba tendrias que modificar el fuente y volver a compilar.

Una estrategia seria tener encriptados en un archivo (puede ser .ini) la informacion de coneexion.

De todas formas recomiendo (y me ha funcionado) que los usuarios se definan a nivel del motor y no dentro de tablas de la propia base de datos.

Sucede que la definicion de usuarios a nivel de motor escasamente nos permite colocar los nombres y apellidos del usuario, el interrogante es donde poner datos como direccion, telefono, cargo, etc.

En ese sentido si defino en mis aplicaciones una tabla (la llamo TS_USUARIO por Tabla del Sistema USUARIO y mi empresa se llama TeraSoft jiji) para los datos complemetarios de los usuarios, incluso tengo un campo ESTADO para indicar si el usuario tiene acceso a la BD o no. Pero alli no coloco nada de claves !!!.

Algunas personas se preguntaran como hago para que el usario no pueda entrar a ciertas partes del programa ?. pues señores para eso son los roles que te restringen hasta donde puede entrar un usuario a las tablas de la BD, y ese rol si lo capturas (tuve que escribir un formulario para eso) como una variable global puedes antes de ingresar a un menu indicar si ese rol tiene permiso para ese menu o no.

Si no cuentan con un programa para manejar los roles prueben con Mitec IBQuery.

Miremos la psobilidad de en colabroacion construir un formulario para ese proposito.

[kinobi]

Hola,

Posteado originalmente por lbuelvas
Algunas personas se preguntaran como hago para que el usario no pueda entrar a ciertas partes del programa ?. pues señores para eso son los roles que te restringen hasta donde puede entrar un usuario a las tablas de la BD, y ese rol si lo capturas (tuve que escribir un formulario para eso) como una variable global puedes antes de ingresar a un menu indicar si ese rol tiene permiso para ese menu o no.


no estoy de acuerdo, amistosamente:) La función de los roles está en el servidor, como forma de agrupar a usuarios con características comunes, pero no tienen (o no deberían tener) ninguna función en el lado cliente.

Con respecto a utilizar una gestión de usuarios diferente a la que proporciona isc4.gdb, también he utilizado en algunas aplicaciones mis propios mecanismos de gestión de usuarios (unas veces en la propia base de datos, otras en una base de datos exclusivamente para esta tarea), pero creo que al final traen más incovenientes que beneficios. Todo funciona correctamente mientras se maneja una base de datos, pero cuando aparecen varias (dentro del mismo sistema) hay que propagar la información de usuarios a todas ellas y mantenerlas actualizas y sincronizadas. Se soluciona con una base de datos centralizada de usuarios, pero para eso ya está isc4.gdb

Saludos.