Estoy hablando de claves privadas del sistema para API, Google Analytics y etc ... (no la clave privada del usuario)
¿Dónde está el mejor lugar para almacenarlo? (Clase de Java, propiedades, archivo oculto, preferencias) (Win multiplataforma, Mac y Linux)
¿Debo cifrar estas claves? Probablemente necesito descifrar antes de que empecemos a usar con un servicio de terceros.
comencemos con este:
¿Debo cifrar estas claves?
1 : Si tiene una máquina de comunicación a máquina o una aplicación a otra, puede usar el cifrado combinado con HMAC y el vector de inicialización (iv) de esta manera, puede proteger sus claves de MITM y ataques similares.
2 : pero si necesita autenticarse en un servidor con una clave no cifrada de esta manera, no podrá protegerlos.
3: protege su aplicación de la ingeniería inversa - > no puedes disculparte, pero puedo darte una lista de técnicas para que sea muy difícil revertirla:
· Anti API Spyer
· Anti Breakpoints
· Anti CrackTools
· Anti DumperPro
· Codificación de código
· Reemplazar código
· Guardia del depurador
· Cifrado dinámico
· Código de basura
· int DebugShield
· Guardia de memoria
· Motor mutador
· Capas polimórficas
· Secure API Wrapper
· Punto de entrada seguro
· Compresión
· Metamorph
· Monitor de Thread Engine
puedes buscar en google para obtener más detalles sobre esta técnica .
¿Dónde está el mejor lugar para almacenarlo?
Si usa el método anterior para proteger su aplicación del reverso, es mejor colocarlos en un campo privado en una clase.
de otra manera, en Linux, póngalos en un archivo como saben, cada cosa en Linux o UNIX es un archivo con 600 como permiso.
en windows ponlos en registro.
- > puede utilizar la técnica de técnica de steganography (marca de agua)
Ha indicado que esto es para una aplicación de escritorio, así que tenga en cuenta que no importa lo que haga, un atacante / ingeniero inverso determinado podrá recuperar estas claves. Si ocultarlos es importante (para que esto sea menos fácil), puede considerar encriptarlos y luego descifrarlos en tiempo de ejecución. Por supuesto, entonces necesitas almacenar esa clave en algún lugar, por lo que tienes un pequeño problema con el huevo y la gallina.
Si hay algo realmente sensible con estas claves (por ejemplo, no solo Google Analytics), querría generar claves por usuario y almacenarlas localmente para ese usuario. (Puede cargar las claves a través de una conexión TLS si es necesario compartirlas con un componente del lado del servidor).
Como David ha indicado, no puede usar ningún dato al que no desea que un cliente tenga acceso en un dispositivo cliente. No importa lo que haga si su aplicación puede extraerlo, el usuario puede hacerlo.
En los casos en los que necesita restringir el acceso solo a los usuarios aprobados, debe autenticar al usuario. O necesita una clave de API para cada usuario aprobado o necesita colocar un servicio de middleware que autentique a los usuarios entre la máquina cliente y la API (supuestamente de terceros).
TL;DR:
Versión más larga: Al responder una pregunta de este tipo, debe tener en cuenta:
No creo que estés protegiéndote del propio usuario (como parecen suponer otros). Usted está protegiendo contra abusadores no legítimos de la aplicación con intenciones maliciosas.
Riesgos: bueno, si se roban las claves, el abusador puede capturar datos, robar cuentas, comprometer los datos o incluso la imagen pública del usuario.
La forma clásica de resolver esto es autenticación / autorización (basada en cadenas de datos memorizadas ("Lo que sabe el usuario") o biométrica ("Propiedades de los usuarios") o propiedad ("Lo que el usuario tiene ", la segunda parte de 2FA)) por la cual se diferencian los usuarios legítimos de los ilegítimos.
En cuanto a ¿Este problema ya ha sido resuelto por otros ? ¿Cómo crees que lo hacen los administradores de contraseñas como keepassX? KeepassX es una base de datos local de contraseñas, archivos clave y otras cadenas de datos confidenciales, esencialmente su problema.
Se usan de 3 maneras (y combinaciones de algunas de ellas): contraseña, clave o un vínculo con las medidas de autenticación existentes (como la cuenta de Windows). Dependiendo de qué tan segura quiera que sea su implementación, elija y elija. Si elige solo la contraseña (como lo haría en la mayoría de los casos), hash con una función criptográfica tiene función, como sha512 + salt o bcrypt así que incluso si un actor malicioso conoce el hash, tiene que hacer un trabajo para adivinar la cadena original. El uso de esta contraseña para cifrar la clave proporcionará la protección necesaria.
No aconsejo usar solo las credenciales de Windows, ya que no es una buena idea no pedirle al cliente una contraseña cuando inicie la aplicación si es una aplicación sensible a la seguridad (nuevamente, así es como lo hace keepassX).