2011-09-06 6 views
5

En mi aplicación C tengo una clave de descifrado que se utiliza para descifrar conjuntos en la base de datos (nombre de usuario/contraseña). Actualmente, simplemente me declaré conContraseñas/claves ocultas en la aplicación compilada

char * key = "$$$secretSampleDecryptionKey$$$"; 

Poco después de esa línea, preparo la instrucción SQL y luego seleccione de la BD. Mi pregunta es si alguien debe depurar mi aplicación compilada o desmontarla, ¿verán realmente la clave? ¿Qué puedo hacer para esconderlo de ellos?

EDIT:

Como Mark y Aaron señalaron, puedo simplemente usar el comando cuerdas Linux/Unix

strings nameOfApplication 

para imprimir todas las cuerdas en mi solicitud, incluyendo la clave "secreta" .

EDIT 2:

La aplicación se ejecuta en mi servidor y las bases de datos almacena datos sensibles del cliente que está cifrada. Pensé que estaba jugando a lo seguro al no tener la clave en un archivo de texto para que todos lo leyeran, sino compilarlo en su lugar.

+4

El comando de picaduras de unix mostrará todo el texto en el archivo, por lo que no es necesario desmontar – Mark

+1

En resumen, lo que haya en la computadora del cliente es tan bueno como rajado. O no pongas nada de interés allí o lo aceptes y salvas a todos los dolores de cabeza;) – delnan

+0

Probé el comando de cadenas y de hecho muestra la clave completa y justo después de esa entrada muestra la declaración sql, para que todos lo supieran. Muchas gracias por señalarme eso. –

Respuesta

8

un enlace interesante que relaciona la historia de alguien recuperar una contraseña de una binaria:

Deconstructing an ELF File

Esta es una descripción paso a paso de lo que alguien podría tratar de descubrir una contraseña. Le dará una idea de lo que "no debe hacer". El uso del comando strings es el primer elemento de la lista, por ejemplo.

Si desea ocultar su cadena secreta de strings, puede almacenarla como una matriz de caracteres no terminada con el carácter \0. strings no debería recogerlo.

También se menciona un buen truco (que se omite) para evitar que alguien use un strace/ltrace en su binario.

En última instancia, al desmontar el código, el "hacker" logra recuperar la contraseña, que como otros han señalado es difícil de proteger. Básicamente no se puede ocultar nada en un archivo binario ...

1

Al usar un depurador/desensamblador, el usuario siempre podrá encontrar la contraseña. Puede hacerlo más difícil (por ejemplo, use obfuscation), pero no imposible.

Si realmente tiene un secreto (es decir, una clave privada necesaria para descifrar los datos), puede realizar el descifrado en una tarjeta inteligente.

En su escenario en relación con los nombres de usuario y contraseña, que sólo podría almacenar la contraseña en hash en la base de datos (ver respuestas se hace referencia en Best way to store password in database)

+0

Gracias Rumpel. Me gusta la idea de almacenar la clave en la base de datos. Al menos es mejor que todos poder leerlo fácilmente. –

1

Puede alguien verlo?

El comando strings mostrará la cadena, sin necesidad de desmontar la aplicación.

Desmontar simplemente hará que sea más fácil identificar cuál de las 15'000 cuerdas se usa como key.

¿Qué puedo hacer para ocultarlo?

Solo hay una solución: No ponerlo en el código.

En su lugar, utilice una clave de licencia o técnica similar donde el usuario conoce la clave.

1

Me pregunto si alguien podría darnos una respuesta real para resolver este problema. Desde mi experiencia como desarrollador web, puedo decirle que lo que le da al cliente ya no le pertenece a usted para controlarlo. Considere un sitio web que utiliza algún algoritmo de encriptación en el lado del servidor y una técnica de javascript codificada en el cliente, y el webdev, él mismo, guiado por su propio tocador, no quiere mostrarlo al mundo, pero aún debe ser utilizado. por los clientes, tal como es.

En este caso, ¿qué puede hacer?Sí, sí, se le ocurre la idea de poner su script en un ciclo infinito basado en setTimeout, todo como una función anónima, por lo que no se puede rastrear, pero la inicialización debe hacerse en alguna parte, el código debe ser Visibile, más aún, decide enviar el código después de la carga de forma encriptada, pero aún así, en el cliente todavía tendrá que tener la clave de descifrado, de modo que quien quiera la información tendrá las dos piezas necesarias de este rompecabezas. . Pero nuestro programador es perseverante, por lo que crea la función de descifrado cada vez para hacer coincidir solo una cadena encriptada, pero aún así no le sirve de nada. Como el cliente todavía tendrá la cadena y la función correspondiente.

Todo lo que puede hacer es encontrar una manera de usar el entorno para que la función se pueda utilizar solo una vez, luego el código caduque como cadena y la información real se pierda para siempre. Y lo más importante es hacer el uso del entorno de tal manera que el contexto de la ejecución de la función de descifrado no se pueda forjar.

Sé que no he respondido a su pregunta, pero le he señalado algunos detalles importantes del problema que ha mencionado. Si trabajas con C, debe haber algunas herramientas que puedas usar, como crear un contexto usando algún estado de memoria o una operación real del sistema para obtener algo que no se pueda falsificar.

EDIT 1: Se puede crear un efect dominó interesante en el código fugas bits de la clave de cifrado basado en la ejecución como cuando se necesita Usted deberá por completo pero no se almacena en un archivo o en una cadena en su archivo compilado, por lo que solo se puede encontrar en tiempo de ejecución, y solo se encuentra en algunas condiciones específicas, y más aún puede tomar algo de ingeniería inversa hrd para obtenerlo. Puede ser una buena solución.

Con gran respeto, Paul

+0

Incluso con el uso de una clave de licencia, como @Aaron mencionó, es problemático, como si realmente quisiera ocultar esa clave, o si desea evitar que otros usuarios la usen, aún es imposible. Solo si todo el mecanismo de código es como basarse en esa cadena para que funcione, y es único en cada sistema. – khael

3

Si la clave está en su fuente, entonces un atacante será podrá encontrarla. Lo mejor que puedes hacer es hacerlo más difícil para ellos.

La clave almacenada no debe ser texto, sino binaria. De esta forma evitará las búsquedas de cadenas. Presumiblemente, si tiene la clave presente en el código, sus usuarios no necesitan poder escribirla.

Almacene la llave en al menos dos matrices binarias de aspecto aleatorio que estén juntas en XOR para formar la clave real.Alternativamente, elija una de las cadenas de texto estándar que están presentes en su aplicación de todos modos, algo así como: "Ingrese el código postal:" y utilícelo como su clave o como un componente del XOR. Hashing un mensaje así lo haría a una longitud estándar si es necesario.

+0

almacenarlos en formato binario tampoco ayuda. Hay herramientas para encontrar claves en archivos binarios, como imágenes de memoria. En lugar de utilizar una cadena que ya está presente, puede usar cualquier secuencia binaria de su programa (tenga cuidado al actualizar el programa, pero de esta manera hay más posibilidades que simplemente usar una cadena). El problema es que con las herramientas de ingeniería inversa un atacante puede averiguar de dónde obtiene la clave. – mrks

+0

@markus: por supuesto. Todo lo que puedes hacer es dificultar al atacante. En algún momento, la clave tendrá que estar en la memoria y el atacante siempre podrá obtenerla desde allí. También es posible un solo paso a través de la pieza apropiada de ensamblador/bytecode. – rossum

Cuestiones relacionadas