¿Cuáles son las soluciones seguras para proteger credenciales importantes en el código fuente [duplicado]?

Hay 2 problemas obvios con las credenciales que se almacenan en el código fuente:

1. El código fuente se puede diseñar fácilmente mediante ingeniería inversa y se pueden extraer las credenciales.
2. Si se filtran las credenciales, tendrá que cambiar la contraseña en el servidor, cambiar la contraseña en el código, reconstruir y volver a implementar

Por lo tanto, una opción para resolver estos dos problemas es no tener las credenciales en el código fuente. Un archivo de configuración adecuadamente protegido puede ser todo lo que necesita, lea las credenciales cuando las necesite, úselas y luego borre la memoria después de usarla.

  

Esto también indica que, ¿qué sucede si tiene información como FTP o la información de inicio de sesión de DB en la aplicación del lado del cliente?

En este caso, parece que desea ocultar las credenciales en su código Java, que son probablemente las constantes de cadena. Si ese es el caso, esta pregunta de StackOverflow puede ser útil .

Lo que quieres (y dije lo que quieres , que no es necesariamente lo que necesitas como se destaca en otras respuestas y comentarios) se llama ofuscación de código .

es un conjunto de técnicas que, dado un código fuente como entrada, producen un código fuente funcionalmente equivalente pero muy difícil de leer / entender en la salida.

Sin embargo, tenga en cuenta las consecuencias, no solo en sentido ascendente sino también en el futuro ya que su software será mucho más difícil de mantener.

Por ejemplo, Java depende mucho de los seguimientos de pila para diagnosticar problemas, por lo general, este rastreo de pila proporciona información clara sobre dónde ocurrió el error. Con un código confuso correctamente, el seguimiento de la pila ya no tendrá significado:

• Los clientes no tendrán medios para resolver incluso los problemas básicos, lo que aumentará las llamadas a sus servicios de soporte.
• Su soporte tendrá menos elementos que investigar del cliente (según mi experiencia, al menos actuando como un cliente para dicha compañía, parece que no tienen un medio fácil para eliminar el ofuscado de su propio seguimiento de pila).

En el ámbito del software corporativo, esto rara vez se usa, ya que el costo generalmente supera los beneficios (pero algunos lo utilizan) y una empresa realmente dispuesta a aplicar ingeniería inversa a su software probablemente lo hará de todos modos.

Este puede ser más frecuente en algunos dominios específicos, como los juegos en línea (MMORPG por ejemplo) dirigidos a una audiencia sustancialmente más amplia y donde los riesgos asociados a la ingeniería inversa pueden ser más alto Sin embargo, esto no cuenta como una protección confiable, solo una medida entre otras diseñada para ralentizar a los atacantes y disuadir a los crackers ocasionales (con las mismas desventajas en cuanto a problemas de soporte y mala relación con el cliente).

Pensemos en qué código es por un segundo. El código es una lista de instrucciones para que un dispositivo (un procesador) haga algo. Los procesadores están diseñados por humanos, por lo que es lógico que un humano pueda entender el código diseñado para él y poder replicar su funcionalidad si se le da suficiente tiempo y esfuerzo.

Lo que estás buscando es esencialmente imposible. Tal vez lo sea con la criptografía cuántica, donde simplemente mirar la información la alterará, pero mientras tanto no lo es.

Tal vez las soluciones que describe sean suficientes para proteger su código. Si solo está tratando de evitar que los niños usen su software, esto funcionará, pero esos mismos niños probablemente nunca tendrán el dinero para comprar su software de todos modos, así que no es como si estuvieran perdiendo mucho. Por otro lado, imagine que cuando era niño se enfrentaba a dos corporaciones, una que le daba el código abiertamente y otra que hacía todo lo posible para evitar que lo usara, una vez que era un adulto con dinero, si tenía que hacer negocios con cualquiera ellos, ¿cuál elegirías? Personalmente elegiría el primero, porque aún me ayudaron mientras no tenía dinero para pagarles. Básicamente, estás ahorrando dinero a corto plazo sin pensar a largo plazo.

Esto es similar a la piratería. Algunas personas invierten una cantidad ilimitada de dinero para tratar de prevenirlo, pero incluso así eventualmente se romperá y todo ese dinero se desperdiciará.

Sugiero un enfoque diferente, en lugar de intentar prevenir el robo / piratería que nunca podrá lograr por completo, trate de atraer a sus clientes que pagan. Haz que valga la pena ser un cliente de pago. Tal vez sea difícil de creer, pero hay personas que están dispuestas a pagar dinero por un buen software. Céntrese en ellos: ¿tienen una solicitud de características o están buscando asistencia técnica? Invierte tu dinero allí.

Si aún quieres intentar proteger tu código, hay una manera de hacerlo. Póngalo en una computadora alojada en casa y manténgala vigilada 24/24. O incluso mejor, ni siquiera escriba código (¿qué pasa si su máquina de desarrollo ya está comprometida?) Y haga lo que haga su valiosa aplicación, pero directamente en su cabeza . Esto debería ser bastante seguro, y no tiene que confiar en un proveedor de hosting ni en los empleados.

Esperamos que esto explique suficientemente bien por qué tienes para confiar en alguien, como un proveedor de infraestructura. Afortunadamente, no todo el mundo es un estafador, y la mayoría de las empresas de infraestructura del lugar felizmente hospedarán su aplicación, ganando mucho dinero con lo que ya hacen mejor sin traicionar su confianza y robar su aplicación.

Recomendaría ofuscación, luego hacer que la contraseña se vea como el código ofuscado y luego dejar un montón de contraseñas de honeypot.