miércoles, 31 de mayo de 2023

Desarrollo seguro: la autenticación

La autenticación determina el acceso a los recursos de un sistema de información, a través de la verificación de la identidad de un usuario o de un dispositivo. Dada su relevancia, la autenticación debe estar presente en el diseño.

Fuente: OptimalIdm

Existen diferentes tipos de autenticación:

  • Autenticación de red: Se utilizan unas credenciales de red (como el usuario+contraseña, un certificado digital, etc.) para acceder al sistema.
  • Autenticación basada en contraseñas: El usuario debe proporcionar su nombre de usuario y su contraseña.
  • Autenticación basada en tokens: Un token único permite acceder al sistema. Dicho token puede ser físico o digital.
  • Autenticación basada en algo poseído: Mediante un soporte que solamente el usuario pueda tener físicamente, como un código QR, una tarjeta de identidad, un smartcard, un USB, un token físico, una tarjeta de coordenadas, etc.
  • Autenticación de dos o más factores: La identidad es requerida mediante varios métodos de identificación, como por ejemplo la contraseña y un SMS. También se lo conoce como 2FA (2 Factor Authentication) y MFA (Multi-Factor Authentication).
  • Autenticación biométrica: La identidad se obtiene a partir de características físicas, tales como la huella dactilar, el iris del ojo, la voz, el reconocimiento facial, etc.
  • Autenticación basada en comportamientos: Uso de patrones de dibujo sobre una pantalla táctil, movimientos de alguna parte del cuerpo, etc.
  • Autenticación basada en ubicación: Por ejemplo, mediante una IP específica.

Posibles riesgos

A continuación se exponen algunas de las amenazas y riesgos posibles relativos a la autenticación:
  • Ataques de diccionario. Pruebas de contraseñas mediante combinaciones comunes y predefinidas de letras y números.
  • Ataques de fuerza bruta. Pruebas de contraseñas generadas mediante combinaciones de caracteres.
  • Ataques Man in the Middle (MitM). Interviniendo las comunicaciones se pueden obtener las credenciales de acceso (contraseñas, tokens, tickets de acceso).
  • Ataques de replay. Si se obtiene un ticket de acceso, éste puede ser reutilizado.
  • Vulnerabilidades de software. Aplicaciones y sistemas operativos con vulnerabilidades.
  • Enumeración de usuarios. Es posible encontrar usuarios registrados probando identidades y analizando las respuestas del servidor (mensajes, tiempos de respuesta, etc).
  • Suplantación de identidad. Se suplanta al servidor de autenticación para engañar al usuario y obtener así sus credenciales.
  • Robo de identidad. Se obtiene la identidad de un usuario, por ejemplo, robando una cookie.

Mejores prácticas

He aquí algunas recomendaciones para tener un alto nivel de seguridad en la autenticación:
  • Las contraseñas han de guardarse en un formato no legible, a ser posible, que la operación de obtener la contraseña en plano sea irreversible, como el uso de hashes fuertes.
  • Proporcionar opciones y enlaces para la desconexión del usuario en la aplicación.
  • Automatizar la desconexión pasado un tiempo de inactividad.
  • No exponer las credenciales en las urls.
  • Los formularios de petición de credenciales deben usar métodos POST.
  • Uso de la autenticación multi-factor en aplicaciones sensibles (múltiples capas de seguridad).
  • Uso del doble factor de autenticación en operaciones críticas, como el cambio de contraseña o el acceso a recursos sensibles.
  • Implementar el bloqueo de una cuenta tras varios intentos de autenticación fallidos.
  • Implementar CAPTCHA para limitar los ataques de fuerza bruta.
  • Usar errores genéricos para evitar la enumeración de usuarios. Por ejemplo: "El usuario y/o la contraseña son incorrectos".
  • Implementar tiempos de espera aleatorios en respuestas a intentos fallidos de autenticación, con lo que se evita la enumeración de usuarios.
  • En la funcionalidad de recuperación de contraseñas, evitar la enumeración de usuarios.
  • El campo de contraseña debe tener desactivado la opción de "autocompletar".
  • Utilizar una buena política de contraseñas:
    • Uso de caracteres alfabéticos, números y caracteres especiales, con distinción de mayúsculas y minúsculas).
    • Longitud amplia (por ejemplo, 16 caracteres).
    • Una contraseña distinta por cada sitio.
    • Establecimiento de una caducidad de contraseña (por ejemplo cada mes). Una vez transcurrido ese tiempo será necesario cambiarla.
  • No almacenar la cookie de autenticación en el navegador del cliente.
  • Cada vez que el usuario se conecte con éxito, la sesión debe ser diferente.
  • Registrar todas las operaciones que afecten a datos sensibles.

Tipos de autenticación más comunes

Autenticación basada en claves

Una autenticación basada en claves (por ejemplo, mediante nombre de usuario y contraseña), es bastante débil en términos de seguridad, se utilice en texto claro, en base64, cifrado o mediante formularios. Sus principales riesgos son:
  • Ingeniería social. 
  • Ataques Man in the Middle (MitM). Un usuario con acceso a la red podría interceptar la información de autenticación.
  • Reutilización de claves. Si se utiliza la misma clave en varios sitios, si se intercepta en uno, el resto queda comprometido.
  • Ataque de fuerza bruta o diccionario. 
  • Autenticación débil. No permite la implementación de medidas de autenticación más seguras, como el MFA o los certificados digitales.

Las mejores recomendaciones son las siguientes:
  • Buena política de contraseñas
  • Uso de autenticación multifactor. Por ejemplo, añadir a la contraseña una verificación de código que se envíe por email, SMS o por aplicaciones externas de autenticación, tales como Google Authenticator o oneLogin Protect.

Autenticación implícita

En este caso, la autenticación no se basa en credenciales proporcionadas por el usuario, si no que la identificación se obtiene automáticamente mediante la dirección IP del usuario, la información de una cookie, un token, etc. Aunque puede ser seguro, existen ciertos riesgos:
  • Acceso no autorizado. Es posible falsificar la ip de un usuario para obtener el acceso. También es posible acceder a la cookie de un usuario y utilizarla para obtener el acceso. 
  • Ataque de fuerza bruta o diccionario. Es vulnerable a este ataque si no usa algoritmos de cifrado robustos. 
  • Autenticación débil. No permite la implementación de medidas de autenticación más seguras, como el MFA o los certificados digitales.
La mejor recomendación es utilizar una contraseña basada en un hash criptográfico lo bastante largo y robusto que haga inútil un ataque de fuerza bruta.


Autenticación de cliente HTTP

Este tipo de autenticación utiliza un par de claves criptográficas para verificar la identidad del usuario o del dispositivo: una clave pública (usada para cifrar la información) y una clave privada (usada para descrifrar la información). Este sistema es bastante seguro y se utiliza para comunicaciones HTTPS, pero su implementación es más compleja y costosa, además de existir otro tipo de riesgos:
  • Acceso no autorizado. Si se obtiene la clave privada del usuario, podemos utilizarla para acceder a los recursos de ese usuario. Por otra parte, si se emite un certificado falso con una clave pública falsa, es posible acceder a recursos protegidos de forma no autorizada.
  • Ataque Man in the Middle (MitM). Es posible interceptar un certificado en tránsito y usarlo para acceder de forma no autorizada.
  • Manipulación de un certificado SSL. En el caso de implementar certificados auto-firmados o certificados no verificados por una CA (Certification Authority).

martes, 30 de mayo de 2023

Desarrollo seguro: todo empieza en la arquitectura

La arquitectura constituye los cimientos sobre los cuales se erigirán nuestras aplicaciones. 

Desarrollo seguro: todo comienza en la arquitectura

Fuente: open stand

Posibles riesgos

El desarrollo seguro comienza con el diseño y la definición de nuestra arquitectura, teniendo en mente las posibles amenazas que pudieran poner en riesgo nuestro sistema, especialmente aquellas derivadas por el uso de componentes que:

  • no estén identificados.
  • sean antiguos o incompatibles, que estén obsoletos o hayan dejado de ser soportados.
  • posean vulnerabilidades conocidas.
  • tengan puertos abiertos no indispensables.

Mejores prácticas

A continuación se detallan las mejores prácticas a la hora de diseñar, definir y mantener una arquitectura segura:
  • Inventario que identifique cada componente de la arquitectura. Todo componente debe estar identificado, o de lo contrario se incurrirá en riesgos de seguridad.
  • Revisión del bastionado de componentes:
    • Identificación de dependencias internas:
      • Módulos.
      • Librerías.
      • Frameworks.
      • Plugins o complementos.
      • Servicios.
      • Otras.
    • Estado de actualización.
    • Configuraciones:
      • Puertos activados (solo los indispensables).
      • Usuarios y contraseñas personalizados (no por defecto).
      • Modo de depuración desactivado.
      • Otras configuraciones de seguridad (ajustadas a una mayor seguridad).
  • Identificación de vulnerabilidades y sus parches de seguridad. En caso de no existir parche:
    • analizar el riesgo y su impacto
    • proponer y adoptar:
      • un plan de vigilancia.
      • un plan de contingencias.
    • realizar un estudio de viabilidad de componentes alternativos.
  • Asegurar la seguridad perimetral lógica mediante la segmentación de red, firewalls, dispositivos IDS, etc.
  • Asegurar la protección de datos mediante:
    • autorización entre entornos.
    • copias de seguridad.
  • Proporcionar un entorno virtual como zona de trabajo, a ser posible, por lenguaje de programación.
  • Mantener las actualizaciones más recientes de:
    • lenguajes de programación
    • paquetes instalados
    • frameworks y librerías
    • herramientas de análisis y seguridad de los IDEs
  • En caso de trabajar con DevSecOps, dotar de herramientas de análisis de seguridad a lo largo del ciclo de vida del software, antes del despliegue en cada entorno.

Referencias