La seguridad móvil es un conjunto de medidas para proteger la aplicación, los datos del usuario y la infraestructura del servidor contra ataques y filtraciones. Según OWASP Mobile Top 10 (2024), el almacenamiento inseguro de datos sigue siendo la vulnerabilidad más común en las aplicaciones móviles. En este artículo analizaremos las principales amenazas, métodos de cifrado, almacenamiento seguro, autenticación y protección de código — todo lo que un desarrollador principiante necesita saber.
Puntos Clave
OWASP (Open Web Application Security Project) es una organización sin fines de lucro que publica un ranking de las vulnerabilidades de seguridad móvil más peligrosas. OWASP Mobile Top 10 es una lista que ayuda a los desarrolladores a entender en qué centrarse primero. En la versión 2024, los problemas relacionados con el almacenamiento inseguro, la autenticación débil y la comunicación de red insegura encabezan la clasificación.
M1: Almacenamiento Inseguro de Datos — el problema más común: contraseñas, tokens y datos personales permanecen en SharedPreferences, NSUserDefaults o archivos locales sin cifrado. M2: Autenticación Débil — falta de verificación del lado del servidor, contraseñas débiles. M3: Comunicación de Red Insegura — falta de HTTPS o verificación incorrecta del certificado SSL. M4 y M5 están relacionados con criptografía y uso incorrecto de la API.
M6: Autorización Insegura — un usuario puede acceder a datos de otro usuario sustituyendo un ID en la solicitud. M7: Inyección de Código (SQL Injection, XSS). M8: Manipulación de la Aplicación — reempaquetado, sustitución de código. M9 y M10 — filtración de datos a través de bibliotecas de terceros e ingeniería inversa. Para cada una de estas amenazas existen contramedidas probadas, y en IT Sectr las aplicamos en todos los proyectos desde 2017.
El ataque MITM ocurre cuando un atacante intercepta el tráfico entre la aplicación y el servidor. Esto es posible mediante suplantación de DNS, ARP spoofing o conexión a una red Wi-Fi no segura. Para la protección se utilizan certificados SSL/TLS y Certificate Pinning.
Certificate Pinning es un mecanismo mediante el cual la aplicación verifica que el certificado del servidor coincide con uno prealmacenado en el código de la aplicación. Incluso si un atacante sustituye el certificado a través de un proxy (por ejemplo, Burp Suite), la aplicación rechazará la conexión. El Pinning es de dos tipos: Public Key Pinning y Certificate Hash Pinning.
AES (Advanced Encryption Standard) es un algoritmo de cifrado simétrico, la base de la seguridad de datos en el dispositivo. AES utiliza la misma clave para cifrar y descifrar datos. AES admite claves de 128, 192 o 256 bits. En el desarrollo móvil, AES-256 se utiliza para cifrar datos en el dispositivo: archivos, caché, registros en la base de datos local.
Modos AES: GCM (recomendado) — proporciona autenticación de datos, CBC — modo básico con encadenamiento de bloques, ECB — inseguro, no lo use. Para iOS, AES está disponible a través de CommonCrypto (CCOptions), para Android — a través de Cipher en Java Cryptography Architecture (JCA). Importante: la clave de cifrado nunca debe almacenarse en el código de la aplicación — use Keychain/Keystore.
Cifrado Asimétrico: RSA — utiliza un par de claves (pública y privada). RSA se usa para cifrar pequeñas cantidades de datos — típicamente para intercambiar una clave simétrica entre cliente y servidor. La longitud mínima de clave RSA es de 2048 bits (se recomienda 4096). En iOS, RSA está disponible a través de Security Framework (SecKeyCreateRandomKey), en Android — a través de KeyPairGenerator en Android Keystore.
Hashing (SHA-256, SHA-3) es una transformación irreversible de datos en una cadena de longitud fija. Los hashes se utilizan para verificar la integridad de los datos y almacenar contraseñas. Para contraseñas, asegúrese de usar bcrypt, scrypt o Argon2 — el SHA-256 simple es vulnerable a ataques de tablas rainbow. SSL/TLS es un protocolo para cifrar el tráfico de red entre cliente y servidor. El estándar moderno es TLS 1.3, que proporciona Perfect Forward Secrecy (PFS).
TLS 1.3 es más rápido que sus predecesores: el handshake toma un round trip en lugar de dos. En Android, la versión mínima de TLS se configura a través de SSLSocket, en iOS — a través de ATS (App Transport Security), que por defecto requiere TLS 1.2 o superior. ATS solo puede deshabilitarse para dominios específicos con justificación.
Keychain es un almacenamiento seguro en iOS / macOS para contraseñas, claves de cifrado, certificados y tokens. Los datos en Keychain se cifran con una clave de hardware única para cada dispositivo. El acceso a Keychain se controla a través de Security Framework (SecItemAdd, SecItemCopyMatching). Keychain se bloquea automáticamente cuando el dispositivo se bloquea y se cifra mediante Secure Enclave.
Android Keystore es un almacenamiento de sistema para claves criptográficas, aislado de la aplicación. A partir de Android 6.0 (API 23), Keystore utiliza soporte de hardware (TEE — Trusted Execution Environment) en dispositivos con chip de seguridad. Las claves en Keystore nunca salen del área segura — la aplicación solo recibe un handle para operaciones de cifrado y firma.
| Parámetro | iOS Keychain | Android Keystore |
|---|---|---|
| Tipo de datos almacenados | Contraseñas, tokens, claves, certificados | Claves criptográficas |
| Soporte de hardware | Secure Enclave (todos los iPhone con A7+) | TEE (Android 6+, depende del chip) |
| Cifrado | AES-256 hardware | AES/GCM con clave de hardware |
| Biometría | Face ID / Touch ID para acceso | BiometricPrompt para acceso |
| iCloud / respaldo | Sincronización vía iCloud Keychain | No se sincroniza con la nube |
| Rendimiento | Más lento (cifrado por hardware) | Más rápido (TEE) |
SharedPreferences y NSUserDefaults no están diseñados para almacenar datos sensibles — almacenan información en texto plano. Para proteger datos, use EncryptedSharedPreferences (Android) o cifre los datos antes de guardarlos en UserDefaults (iOS). En IT Sectr, siempre usamos Keychain y Keystore para tokens de acceso y contraseñas.
OAuth 2.0 es un protocolo de autorización delegada que proporciona acceso seguro a los recursos del usuario sin transmitir la contraseña. En aplicaciones móviles, el más utilizado es Authorization Code Flow con PKCE (Proof Key for Code Exchange). PKCE evita la interceptación del código de autorización — un requisito obligatorio para aplicaciones móviles.
OpenID Connect (OIDC) es una extensión sobre OAuth 2.0 para la autenticación de usuarios. OIDC agrega un ID Token en formato JWT que contiene información del usuario (nombre, email, id). El flujo OAuth 2.0 + OIDC incluye: redirigir al usuario a la página de inicio de sesión, obtener un código de autorización, intercambiar el código por tokens (access + refresh + id), usar el access token para solicitudes API.
JWT (JSON Web Token) es un formato de token compacto y seguro para URL que contiene claims en formato JSON. JWT consta de tres partes: header (tipo y algoritmo de firma), payload (datos) y signature (firma). Access Token es un token de corta duración (15–60 minutos) para acceso a API. Refresh Token es un token de larga duración (días/semanas) para obtener un nuevo access token sin reiniciar sesión.
Session Token es un enfoque tradicional donde el servidor almacena la sesión en una base de datos o Redis, y el cliente recibe un identificador aleatorio. En el desarrollo móvil, se prefiere JWT: no requiere almacenamiento de sesiones del lado del servidor, contiene toda la información dentro de sí mismo y es fácil de verificar. Sin embargo, JWT no se puede revocar instantáneamente — esta es una compensación que se resuelve con un tiempo de vida corto del access token y el uso de refresh tokens.
Face ID y Touch ID en iOS, Fingerprint Auth en Android — métodos de autenticación biométrica que utilizan características físicas únicas del usuario. En iOS, la biometría funciona a través de LocalAuthentication (LAContext), en Android — a través de BiometricPrompt (Android 9+) o FingerprintManager (obsoleto). La biometría se utiliza para desbloquear la aplicación, confirmar pagos y acceder a datos protegidos.
Matices importantes: la biometría es una UX conveniente, pero no reemplaza la autenticación del servidor. Después de una verificación biométrica exitosa, la aplicación debe obtener un access token del servidor. En Android, asegúrese de verificar que el dispositivo use biometría Clase 3 (Fuerte), no solo reconocimiento facial basado en cámara (Clase 1).
ProGuard es una herramienta de ofuscación, compresión y optimización de bytecode Java para Android, que mejora la seguridad del código contra la ingeniería inversa. R8 es su sucesor, integrado en Gradle desde Android Studio 3.4. R8 realiza cuatro tareas: compresión (elimina clases y métodos no utilizados), optimización (inlinea métodos, simplifica código), ofuscación (renombra clases y métodos a nombres cortos) y pre-verificación (verificación de bytecode).
DexGuard es una versión comercial de ProGuard con protección mejorada: cifrado de cadenas, ofuscación de recursos, protección contra reempaquetado, control de integridad APK. Para la mayoría de los proyectos, R8 es suficiente, pero para aplicaciones financieras y bancarias, DexGuard proporciona una capa adicional de seguridad. R8 se habilita a través de build.gradle: minifyEnabled = true y proguardFiles.
Root Detection (Android) y Jailbreak Detection (iOS) son mecanismos que verifican si se han obtenido privilegios de superusuario en el dispositivo. En dispositivos comprometidos, es posible leer la memoria del proceso, interceptar el tráfico y sustituir código. Para la verificación en Android, se utiliza la presencia del archivo binario SU, claves de firma de prueba y flags de compilación no estándar.
RASP (Runtime Application Self-Protection) es una tecnología que protege la aplicación durante la ejecución. RASP detecta intentos de depuración, reempaquetado, inyección de código y finaliza la aplicación cuando se detectan amenazas. Ejemplos de soluciones RASP: Dexter, Guardsquare, Promon. RASP funciona en tiempo de ejecución y reacciona a anomalías — a diferencia de la ofuscación estática, que protege el código antes de la ejecución.
Ingeniería Inversa es el proceso de recuperar el código fuente a partir de una aplicación compilada. Herramientas: JADX (decompilador APK), Ghidra, IDA Pro, Hopper. La protección contra la Ingeniería Inversa es una combinación de ofuscación, cifrado de cadenas, verificación de integridad y Root Detection. No existe protección completa — el objetivo es hacer que la ingeniería inversa sea lo suficientemente costosa para el atacante.
Preguntas Frecuentes
Comience con OWASP Mobile Top 10 — es una hoja de ruta de las vulnerabilidades más comunes. Luego estudie HTTPS y certificados SSL, configure Certificate Pinning y pase al almacenamiento seguro mediante Keychain / Keystore.
AES (simétrico) — una clave para cifrar y descifrar, rápido, adecuado para grandes volúmenes de datos. RSA (asimétrico) — un par de claves (pública y privada), más lento, utilizado para intercambiar la clave simétrica.
Debe cifrar solo datos confidenciales: contraseñas, tokens, datos personales del usuario, información de pago. Las imágenes, los textos y la configuración de la interfaz no requieren cifrado — esto aumentaría el tamaño y ralentizaría la aplicación.
Refresh Token es un token de larga duración que permite obtener un nuevo Access Token sin volver a introducir la contraseña. Esto mejora la seguridad — el Access Token vive de 15 a 60 minutos, e incluso si se filtra, el atacante no puede usarlo por mucho tiempo.
Sí, R8 debe activarse para las compilaciones de lanzamiento de Android. No solo es protección contra Ingeniería Inversa, sino también reducción del tamaño del APK y optimización del rendimiento. Sin R8, su código se puede descompilar en forma legible con un solo comando de JADX.
Resumen
Desarrollaremos una aplicación móvil llave en mano
IT Sectr crea aplicaciones para iOS y Android para startups y empresas desde 2017. Le asesoraremos y le propondremos la mejor solución.