Las prácticas de seguridad iOS consiste en garantizar que todas las acciones que los usuarios realicen sean seguras, por ello, al desarrollar cualquier aplicación móvil que procese datos de usuario, es importante prestar atención a las buenas prácticas de seguridad.
En el presente artículo, te ofrezco las prácticas de seguridad más comunes a tener en cuenta.
Almacenamiento de datos sensibles
Las aplicaciones a menudo necesitan acceso a datos sensibles del usuario, pero mantener la seguridad de los datos puede tener un costo: si almacena datos sin cifrarlos, crea un riesgo de seguridad.
Las mejores prácticas de seguridad móvil se aplican tanto a los dispositivos móviles utilizados en entornos empresariales, como para uso personal, y las pautas son en gran medida las mismas en ambos escenarios.
La seguridad es obligatoria y afortunadamente, Apple trabaja muy duro para equilibrar la seguridad con la usabilidad.
UserDefaults no son seguros, Por qué
Una de las formas más comunes de guardar configuraciones personalizadas y propiedades de la aplicación es usar UserDefaults. La información almacenada en UserDefaults se conserva incluso después de cerrar y reiniciar la aplicación.
Algunas aplicaciones utilizan UserDefaults para almacenar información confidencial.
Mucha gente no entiende que la información almacenada en UserDefaults no está encriptada y se puede obtener fácilmente del paquete de la aplicación, ya que se almacena en un archivo plist.
UserDefault es para los detalles que son específicos de la aplicación, como configuraciones, preferencias o algunas configuraciones que no son sensibles a la seguridad.
Pero, datos confidenciales y contraseñas no se recomienda almacenar en UserDefaults. Para ello, se deben utilizar servicios como llavero que están encriptados para dichos datos.
Seguridad iOS: Keychain mejor práctica
Los servicios de Keychain API proporcionan un fácil acceso al almacenamiento cifrado. Es el mejor lugar para almacenar pequeñas cantidades de datos confidenciales que no necesitan un acceso frecuente.
Los datos que se almacenan en Keychain son administrados por el sistema operativo, pero no son accesibles por ninguna otra aplicación.
Establezca las condiciones de acceso
En algunos casos, es posible que desee realizar distintas restricciones de la accesibilidad.
Por ejemplo, de forma predeterminada, solo puede acceder a los elementos del llavero cuando el dispositivo está desbloqueado.
Sin embargo, un dispositivo que no está protegido por una contraseña siempre está desbloqueado, por lo que es posible que desee restringir más el acceso e insistir en que solo se puede acceder a un elemento desde un dispositivo protegido por una contraseña.
Alternativamente, puede relajar las restricciones de acceso para poder acceder a un elemento desde un proceso en segundo plano cuando el dispositivo está bloqueado.
Los servicios de Keychain ofrecen formas de administrar la accesibilidad de los elementos individuales del llavero de acuerdo con el estado del dispositivo, combinados con las entradas del usuario.
Controlar el acceso según el estado del dispositivo
Puede controlar el acceso de una aplicación a un elemento de Keychain en relación con el estado de un dispositivo estableciendo el atributo del elemento cuando crea el elemento.
Exigir la presencia del usuario
Permitir el acceso solo cuando el dispositivo está desbloqueado puede no ser lo suficientemente seguro en todos los casos.
Si la aplicación proporciona control directo sobre una cuenta bancaria, puede verificar la presencia del usuario autorizado en el último minuto antes de recuperar las credenciales de inicio de sesión del llavero.
Esto ayuda a proteger la cuenta incluso si el usuario entrega el dispositivo en un estado desbloqueado a otra persona.
Imponga esta restricción proporcionando una instancia como valor para el atributo al crear un elemento de Keychain.
Requerir una contraseña
Además de requerir un estado de dispositivo particular y la presencia de un usuario, puede solicitar una contraseña específica de la aplicación, que protege específicamente un elemento de Keychain en particular.
Haga esto incluyendo la opción application Password, así, el sistema solicita al usuario una contraseña al crear el elemento y luego nuevamente antes de recuperarlo.
El elemento solo se puede recuperar si el usuario ingresa correctamente la contraseña, independientemente de si se cumplen otras condiciones.
Transporte seguro de datos (Secure Data Transportation)
Un aspecto importante de la seguridad informática es la comunicación segura de datos a través de una red.
A partir de iOS 9, Apple decidió imponer requisitos estrictos para las conexiones de red y desarrolló reglas de seguridad de transporte de aplicaciones (ATS).
HTTPS siempre
Según estas reglas, todas las solicitudes a Internet deben realizarse mediante el protocolo HTTPS y cifrarse mediante TLS 1.2 (con soporte de confidencialidad directa).
Si los puntos finales de la API permiten que los usuarios de la API se comuniquen a través de http u otros protocolos inseguros, un atacante puede acceder fácilmente a la información transmitida y «robar» datos personales.
Por lo tanto, siempre haga que https sea la única opción disponible.
No importa cuán triviales puedan parecer los puntos finales, conectarse a http ni siquiera debería ser una opción.
El sistema operativo en sí sigue estos requisitos de forma predeterminada, por lo que solo debe cumplirlos en el lado del servidor.
Fijación SSL
Incluso cuando se utilizan conexiones HTTPS, es posible que terceros vean los datos al intercambiar con el servidor. Puede combatir esto con la fijación SSL.
En la práctica, esto significa que la aplicación conoce el certificado SSL del servidor utilizado para la conexión HTTPS y no confía en otros certificados.
Al recibir un certificado desconocido del servidor, la conexión finaliza.
La fijación se puede realizar de diferentes formas: almacenar el archivo de certificado en sí, su hash o clave pública en la aplicación.
Si usa un hash o un certificado, al caducar tiene que lanzar una actualización de la aplicación con nuevos datos, de lo contrario simplemente dejará de funcionar.
Al usar la clave pública y regenerar el certificado del servidor, no será necesario actualizar la aplicación, ya que la clave pública seguirá siendo la misma.
Seguridad iOS: Usar cryptographic APIs
Apple proporciona bibliotecas que incluyen implementaciones de los algoritmos criptográficos más comunes.
Apple CryptoKit se lanzó con iOS 13 y está construido sobre la biblioteca criptográfica nativa de Apple. El marco Swift proporciona una interfaz API, con una gestión de memoria eficaz, se ajusta a la igualdad y admite genéricos.
CryptoKit contiene algoritmos seguros para hash, criptografía de clave simétrica y criptografía de clave pública. El marco también puede utilizar el administrador de claves basado en hardware de Secure Enclave. Corecrypto
Bibliotecas
La clase más utilizada para operaciones criptográficas es CommonCrypto, que incluye el tiempo de ejecución de iOS.
Desafortunadamente, CommonCryptor carece de algunos tipos de operaciones en sus API públicas. Para esto, se pueden usar otras bibliotecas de envoltura.
Para operaciones asimétricas, Apple proporciona SecKey. Existen algunas bibliotecas contenedoras para ambos con el fin de brindar comodidad.
Las bibliotecas típicas que se utilizan son, por ejemplo: IDZSwiftCommonCrypto, Heimdall, SwiftyRSA, SwiftSSL, RNCryptor, arcano.
También hay varias bibliotecas de terceros disponibles, como: CJOSE, CryptoSwift, OpenSSL (kit de herramientas utilizadas para TLS), LibSodium, además, hay algunas bibliotecas de envoltura, como Swift-sodium, NAChloride y libsodium-iOS.
Seguridad iOS: Hashing data
En muchas aplicaciones, la autorización se produce introduciendo un código PIN de 4 a 6 dígitos, inventado por el usuario durante el registro. Naturalmente, no puede almacenar este código en su forma pura ni en el dispositivo ni en el servidor.
Hash de contraseña
La verificación del código ingresado para chequear que sea correcto debe tener lugar en el servidor, donde se envía en forma de hash obtenido mediante el algoritmo PBKDF2.
Para que este algoritmo funcione, necesita una token, un conjunto de caracteres aleatorios que se genera una vez al registrarse y se utiliza para todas las autorizaciones posteriores.
En el mejor de los casos, solo esta token debe almacenarse en la base de datos de la aplicación.
Pero las aplicaciones a menudo ofrecen la opción de iniciar sesión con Touch ID y Face ID. En tales situaciones, debe almacenar en el llavero tanto el código PIN como el hash obtenido de él.
La cantidad de intentos posibles para ingresar el código PIN es limitada y la limitación debe ser impuesta por el servidor. Después de usar todos los intentos, los datos almacenados en el disco se borran y el usuario se desconecta automáticamente.
Hash evaluado Policy Domain State
Un atacante podría agregar su huella dactilar a la lista de huellas dactilares conocidas por el sistema y utilizarla para iniciar sesión en la aplicación sin conocer el código PIN.
Para resolver este problema, el sistema operativo proporciona un hash llamado evaluado Policy Domain State que describe el conjunto actual de huellas digitales.
Este hash se puede guardar en el disco durante la primera autorización exitosa en la aplicación, y durante las autorizaciones posteriores, puede verificar si el valor actual difiere del guardado.
Si son diferentes, la base de datos de huellas digitales se ha cambiado, el inicio de sesión con Touch ID queda deshabilitado y el usuario debe volver a ingresar el código PIN de la aplicación para guardar el nuevo valor hash. Lo mismo se aplica a Face ID.
Conclusión
Hemos visto que la seguridad iOS se puede mejorar poniendo en práctica las recomendaciones más comunes señaladas en este artículo, y obtener una compensación razonable entre seguridad y accesibilidad.
Finalmente, recuerde que la protección de los datos del usuario debe ser siempre la prioridad, en ese sentido debe proporcionar aplicaciones iOS seguras y robustas.
¿Qué te pareció las mejores prácticas de seguridad iOS? Dejame tu comentario y no te olvides de compartirla 😄