Primera regla de seguridad de la aplicación: cualquier máquina a la que un atacante obtenga acceso físico o electrónico sin restricciones ahora pertenece a su atacante, independientemente de dónde se encuentre realmente o de lo que haya pagado.
Segunda regla de seguridad de la aplicación: cualquier software que deje los límites físicos dentro de los cuales un atacante no puede penetrar ahora pertenece a su atacante, independientemente de cuánto tiempo haya dedicado a codificarlo.
Tercera regla: cualquier información que deje esos mismos límites físicos que un atacante no puede penetrar ahora pertenece a su atacante, sin importar lo valioso que sea para usted.
Los fundamentos de la seguridad de la tecnología de la información se basan en estos tres principios fundamentales; la única computadora verdaderamente segura es la que está encerrada en una caja fuerte, dentro de una jaula Farraday, dentro de una jaula de acero. Hay computadoras que pasan la mayor parte de su vida útil solo en este estado; una vez al año (o menos), generan las claves privadas para las autoridades de certificación raíz de confianza (frente a una gran cantidad de testigos con cámaras que graban cada centímetro de la habitación en la que se encuentran).
Ahora, la mayoría de las computadoras no se utilizan en este tipo de entornos; están físicamente al aire libre, conectados a Internet a través de un canal de radio inalámbrico. En resumen, son vulnerables, como es su software. Por lo tanto, no se puede confiar en ellos. Hay ciertas cosas que las computadoras y su software deben saber o hacer para ser útiles, pero se debe tener cuidado para garantizar que nunca puedan saber o hacer lo suficiente como para causar daños (al menos no daños permanentes fuera de los límites de esa única máquina )
Ya sabías todo esto; Es por eso que está tratando de proteger el código de su aplicación. Pero, ahí radica el primer problema; las herramientas de ofuscación pueden hacer que el código sea un desastre para que un humano intente cavar, pero el programa aún tiene que ejecutarse; eso significa que el flujo lógico real de la aplicación y los datos que usa no se ven afectados por la ofuscación. Dada un poco de tenacidad, un atacante puede simplemente desenmascarar el código, y eso ni siquiera es necesario en ciertos casos donde lo que está mirando no puede ser otra cosa que lo que está buscando.
En cambio, debe intentar asegurarse de que un atacante no pueda hacer nada con su código, sin importar cuán fácil sea para él obtener una copia clara del mismo. Eso significa que no hay secretos codificados, porque esos secretos no son secretos tan pronto como el código abandona el edificio en el que lo desarrolló.
Estos valores clave que ha codificado deben eliminarse por completo del código fuente de la aplicación. En cambio, deberían estar en uno de los tres lugares; memoria volátil en el dispositivo, que es más difícil (pero aún no imposible) para un atacante obtener una copia fuera de línea; permanentemente en el clúster de servidores, al que controla el acceso con un puño de hierro; o en un segundo almacén de datos no relacionado con su dispositivo o servidores, como una tarjeta física o en las memorias de su usuario (lo que significa que eventualmente estará en una memoria volátil, pero no tiene que ser por mucho tiempo).
Considere el siguiente esquema. El usuario ingresa sus credenciales para la aplicación desde la memoria al dispositivo. Desafortunadamente, debe confiar en que el dispositivo del usuario no esté comprometido por un keylogger o un troyano; lo mejor que puede hacer a este respecto es implementar la seguridad multifactor, recordando información de identificación difícil de falsificar sobre los dispositivos que ha utilizado el usuario (MAC / IP, IMEI, etc.) y proporcionando al menos un canal adicional al que se puede verificar un intento de inicio de sesión en un dispositivo desconocido.
Las credenciales, una vez ingresadas, son ofuscadas por el software del cliente (utilizando un hash seguro), y las credenciales de texto sin formato se descartan; Han cumplido su propósito. Las credenciales ofuscadas se envían a través de un canal seguro al servidor autenticado con certificado, que las vuelve a cifrar para generar los datos utilizados para verificar la validez del inicio de sesión. De esta manera, el cliente nunca sabe qué se compara realmente con el valor de la base de datos, el servidor de aplicaciones nunca conoce las credenciales de texto sin formato detrás de lo que recibe para la validación, el servidor de datos nunca sabe cómo se producen los datos que almacena para la validación, y un hombre en el centro solo ve galimatías incluso si el canal seguro se vio comprometido.
Una vez verificado, el servidor transmite un token por el canal. El token solo es útil dentro de la sesión segura, está compuesto de ruido aleatorio o una copia encriptada (y por lo tanto verificable) de los identificadores de sesión, y la aplicación cliente debe enviar este token en el mismo canal al servidor como parte de cualquier solicitud hacer algo. La aplicación cliente lo hará muchas veces, porque no puede hacer nada que involucre dinero, datos confidenciales o cualquier otra cosa que pueda ser dañina por sí misma; en su lugar, debe pedirle al servidor que realice esta tarea. La aplicación cliente nunca escribirá ninguna información confidencial en la memoria persistente del dispositivo, al menos no en texto plano; el cliente puede pedirle al servidor a través del canal seguro una clave simétrica para encriptar cualquier dato local, que el servidor recordará; en una sesión posterior, el cliente puede pedirle al servidor la misma clave para descifrar los datos para usar en la memoria volátil. Esos datos tampoco serán la única copia; cualquier cosa que el cliente almacene también debe transmitirse de alguna forma al servidor.
Obviamente, esto hace que su aplicación dependa en gran medida del acceso a Internet; el dispositivo cliente no puede realizar ninguna de sus funciones básicas sin una conexión y autenticación adecuadas por parte del servidor. No es diferente a Facebook, de verdad.
Ahora, la computadora que el atacante quiere es su servidor, porque no es la aplicación / dispositivo del cliente lo que le puede hacer ganar dinero o causar dolor a otras personas por su disfrute. Está bien; obtienes mucho más por tu dinero gastando dinero y esfuerzo para proteger el servidor que al tratar de proteger a todos los clientes. El servidor puede estar detrás de todo tipo de cortafuegos y otros dispositivos de seguridad electrónica, y además puede estar físicamente asegurado detrás de acero, concreto, acceso con tarjeta / pin y vigilancia por video las 24 horas. Su atacante necesitaría ser muy sofisticado para obtener cualquier tipo de acceso al servidor directamente, y usted (debería) saberlo de inmediato.
Lo mejor que puede hacer un atacante es robar el teléfono y las credenciales de un usuario e iniciar sesión en el servidor con los derechos limitados del cliente. Si esto sucede, al igual que perder una tarjeta de crédito, se debe indicar al usuario legítimo que llame al número 800 (preferiblemente fácil de recordar, y no en el reverso de una tarjeta que llevarían en su bolso, billetera o maletín que podría ser robado junto con el dispositivo móvil) desde cualquier teléfono al que puedan acceder que los conecte directamente a su servicio al cliente. Afirman que su teléfono fue robado, proporcionan un identificador único básico, y la cuenta está bloqueada, cualquier transacción que el atacante haya podido procesar se revierte, y el atacante vuelve al punto de partida.