¿Cómo puedo descifrar los datos con Java sin tener que codificar la clave?

13

Espero que esto no sea un problema de huevo de gallina o reinventar la rueda, pero aquí va.
Tengo una aplicación Java que necesita acceder a un archivo protegido por contraseña (en realidad durante el inicio de la aplicación).
La ruta del archivo protegido por contraseña a la que se debe acceder está en un archivo de configuración y la contraseña encrypted también está en este archivo de configuración.
Entonces, el problema es cómo descifrar la contraseña cifrada para poder acceder al archivo.
Podría simplemente codificar la clave de descifrado en mi código y poder descifrarla.
Pro:

  • funciona

Con:

  1. No puedo usarlo ya que el código no está ofuscado (no puede ser por varias razones) y se puede encontrar la clave de descifrado
  2. La contraseña no se puede cambiar ya que el descifrado se cifraría en la aplicación

Nota: Me importa principalmente sobre (1); (2) se desea pero no es necesario para mí.

Entonces, ¿hay un enfoque bueno / estándar para esto?

Cualquier entrada es muy apreciada.

    
pregunta Jim 25.08.2011 - 17:04
fuente

5 respuestas

14

Debe almacenar una "contraseña" (o contraseña para descifrar la contraseña o contraseña para descifrar la contraseña para descifrar la contraseña, etc. hasta el infinito), en algún lugar.

Por lo tanto, o bien puede almacenarlo

  • en la computadora, pero luego puede ser desofuscado y leído (si su programa puede hacerlo, cualquier programa puede hacerlo)
  • o en la cabeza del usuario (es más difícil de programar programáticamente, pero tiene su propio conjunto de problemas: 12345 , notas Post-It, etc.)
  • o en un dispositivo que el usuario lleva consigo (es probable que se pierda o sea robado, más caro)

Dependiendo de lo que esté protegiendo (¿una bóveda de banco o imágenes lolcat?), estos enfoques se pueden combinar o usar por separado. También debe tener en cuenta la fuerza de cifrado, además de la fuerza de la contraseña: "no tiene sentido usar una puerta de bóveda en un cobertizo de jardín que tiene una ventana en la parte posterior".

    
respondido por el Piskvor 25.08.2011 - 18:57
fuente
7

En su corazón, esta es una pregunta sobre Control. Desea controlar el acceso a este archivo KeyStore, de modo que solo su aplicación pueda acceder a él pero nadie más pueda hacerlo. No querrá poner demasiados pocos Controles en esto, porque eso abriría la posibilidad de acceso no autorizado. Tampoco quiere poner demasiados controles en esto, porque sería demasiado engorroso y costoso de usar.

Para permitir que la aplicación, y no otra persona, acceda a su KeyStore, debe habilitar la aplicación para afirmar una identidad.

Tienes las siguientes opciones:

  1. Coloque la frase de contraseña en el KeyStore en un archivo de configuración y haga que la aplicación lea esto al inicio. Esto le permite controlar la identidad de la instancia de la aplicación mediante la manipulación de los permisos del sistema de archivos (el usuario de la aplicación puede leer, pero no escribir, y nadie más puede leer). Si su Almacén de claves se basa únicamente en el archivo del Almacén de claves, considere colocar los controles de permiso del sistema operativo en el archivo del Almacén de claves y eliminar por completo la frase de contraseña. Si su adversario puede hacerse pasar por el usuario de su aplicación, tiene una raíz en su sistema y usted tiene problemas mucho mayores.
  2. Cuando se inicie la aplicación, pídale a alguien que escriba la frase de acceso a KeyStore en la consola antes de que la aplicación cargue el KeyStore. Esto obviamente cae directamente en la categoría "engorroso": evita el inicio automático, y puede ser atacado sobornando a las personas que tienen que saber la contraseña.
  3. Use un Módulo de seguridad de hardware (HSM) para realizar una copia de seguridad del Almacén de claves de modo que la subversión de la seguridad del sistema de archivos en el servidor de la aplicación tenga que combinarse con un ataque físico en la instalación de alojamiento antes de poder usar las claves. Las mismas consideraciones mencionadas anteriormente para la seguridad de las credenciales utilizadas para iniciar sesión en el HSM. Aquí es donde tengo que revelar que vendo los HSM para ganarme la vida.
  4. Use un HSM en combinación con controles de acceso forzados por HSM para que múltiples operadores tengan que proporcionar una credencial de hardware (tarjeta inteligente) y escribir una frase de contraseña en la consola del sistema antes de que la aplicación pueda iniciarse. Este es el extremo opuesto de "engorroso", pero protege contra el problema del soborno en 2. arriba.

Tenga en cuenta que ninguno de estos se basa en agregar capas de cifrado: se trata de hacer cumplir los Controles en el acceso a los contenidos de KeyStore, según la identidad de una instancia de la aplicación o la autorización de uno o más operadores.

Al final, todo depende de qué tan importante es esa clave privada y cuáles son las consecuencias cuando esa clave privada se pierde o se ve comprometida. Los controles que se deben utilizar deben ser una decisión comercial, según su evaluación de los riesgos y consecuencias.

    
respondido por el Sander Temme 26.08.2011 - 23:07
fuente
4

¿Contra quién está protegiendo este archivo?

Si está en contra de procesos que se ejecutan con los mismos permisos o menos, entonces java.security.KeyStore debe permitir al usuario autorizar su proceso para acceder a la clave con una contraseña de su elección. Aún debe establecer una ruta de confianza para esa solicitud de autorización.

Si está tratando de protegerse contra los procesos que se ejecutan como superusuario o con la capacidad de interceptar eventos de UI para todo el sistema de ventanas, entonces tiene que renunciar a un almacén de claves protegido por contraseña.

    
respondido por el Mike Samuel 25.08.2011 - 20:59
fuente
3

Dado que la contraseña protege la clave privada del usuario, antes de usar la clave privada, debe asegurarse de que el usuario la autorice. La forma más lógica de garantizar que el usuario autorice un acceso es pedirle una contraseña. Por lo tanto, es difícil entender cómo esto podría ser un problema.

    
respondido por el David Schwartz 27.08.2011 - 17:01
fuente
1

Este parece ser uno de los problemas perennes con la seguridad. No querrá que la contraseña esté en texto simple, porque si la ejecuto a través de JAD y veo su cadena de conexión, quedaría menos impresionada. Por lo tanto, almacenarlo en la aplicación suele ser mal visto, independientemente de la ofuscación o no. Dicho esto, la contraseña debe almacenarse en algún lugar, generalmente como parte de la configuración (archivo de propiedades) o dentro de la base de datos que utiliza el sistema.

Con el enfoque del archivo de propiedades, se debe leer solo para el usuario que lo necesita, la cuenta de servidor web sin privilegios que no pertenece a ningún grupo y solo tiene privilegios de RX o RW según sea necesario. Ahora, el problema aquí es que en el segundo en que la aplicación lo lea, cualquiera puede obtenerlo, pero es necesario.

Con la base de datos tenemos otro conjunto de problemas, si el atacante compromete la cuenta de usuario sin privilegios que está ejecutando la base de datos, este no debería ser el servidor web; El precio de uno. Esta sería una mala forma de comprometerse ya que demuestra la falla en el diseño inicial del sistema.

    
respondido por el Woot4Moo 26.08.2011 - 01:58
fuente

Lea otras preguntas en las etiquetas