Almacenamiento de claves API en Android, ¿es obfustificación suficiente?
Estoy utilizando la API de Dropbox. En la aplicación de ejemplo, incluye estas líneas:
// Replace this with your consumer key and secret assigned by Dropbox. // Note that this is a really insecure way to do this, and you shouldn't // ship code which contains your key & secret in such an obvious way. // Obfuscation is good. final static private String CONSUMER_KEY = "PUT_YOUR_CONSUMER_KEY_HERE"; final static private String CONSUMER_SECRET = "PUT_YOUR_CONSUMER_SECRET_HERE";
Soy muy consciente del mantra "El secreto no es la seguridad", y la ofuscación realmente sólo aumenta ligeramente la cantidad de esfuerzo requerido para extraer las claves. Estoy en desacuerdo con su afirmación "La ofuscación es buena". ¿Qué debo hacer para proteger las llaves entonces? ¿Es la obfustificación lo suficientemente buena, o debo considerar algo más elaborado?
- Dropbox Sync API - Error de enlace no satisfecho
- API de Dropbox de Android que no guarda el inicio de sesión
- Uso de Proguard para obfuscar la aplicación Android con las bibliotecas de Dropbox.com
- Documentación de Dropbox android sdk
- Uso de los detalles de autenticación de Dropbox guardados en Android
- Dropbox SDK para Android: no puede encontrar AndroidAuthSession
- Lectura del archivo .txt desde un enlace compartido desde un dropbox Android studio
- ¿Cómo puedo obtener mi APP_KEY y SECRET_KEY para la sincronización de Dropbox?
- Integre Dropbox en la aplicación Android, pero sin iniciar sesión
- Gradle release build con proguard: java.lang.IncompatibleClassChangeError y java.lang.NoSuchMethodError
- Archivo de carga de Android en Google Drive y Dropbox
- Cómo importar Dropbox Chooser SDK en Android Studio?
- Permitir que la API de Dropbox acceda a mi cuenta en el dispositivo del usuario
No puedes evitarlo. Si el usuario (atacante) tiene los datos protegidos y el código que hace la desprotección, el usuario puede eventualmente tener acceso a los datos. Es tan simple como eso. Un depurador y un punto de interrupción en el momento justo es todo lo que necesitan. Eso, y mucho tiempo libre y determinación.
Si o no secreto es lo suficientemente bueno para sus propósitos es hasta sus detalles de negocios. Pero generalmente en el mundo móvil, si el cliente está preocupado por sus datos robados, implementan controles de alto nivel de robo y pérdida. Cosas como la limpieza remota, bloqueo de pantalla obligatorio, etc No creo que sea hasta el programador de aplicaciones para duplicar todo eso.
La seguridad nunca puede ser perfecta, así que depende de usted decidir cuánto trabajo desea hacer. Usted puede romper el secreto del consumidor en varias cadenas para un cambio simple que ofrece una cantidad mínima de seguridad adicional o puede crear un algoritmo para representar el secreto de otra manera (cualquier cosa de la inserción de caracteres que no se utilizan cada X espacios en la cadena A la modificación de cada carácter, tal vez basado en la representación numérica).
Tienes que considerar el trabajo vs. beneficio. Si se trata de una aplicación que usted y algunos amigos van a utilizar, entonces probablemente no importa mucho. Si esto va a ser una aplicación utilizada por 10 millones de personas, la seguridad es obviamente más una preocupación.
- Cómo obtener malformado JSON en Retrofit 2
- Android – mapas offline, no basados en vectores, personalizados