Nociones breves acerca de la necesidad de la protección de los datos (o la trilogía de como ser un desarrollador cuqui sin llamarse Borja Mari…)

Nociones breves acerca de la necesidad de la protección de los datos:

Introducción:

Antes de comenzar a daros la paliza con una de mis infumables chapas de desarrollo seguro y demás, quisiera dedicar unas breves palabras, este año 2018 ha sido un año … interesante podríamos decir. Un año con muchos cambios y movimiento en lo profesional y en lo personal. Los cambios son buenos y el salir de nuestra zona de confort, a pesar del lógico respeto que da, también es bueno. Aprovecho este modesto lugar en internet para desear lo mejor a mi amigo Byt3St0rm, que se fue en busca de su sueño a lejanas tierras allende los mares, si hubiera más soñadores así, posiblemente el mundo sería un lugar mejor.

Desde estas humildes palabras de este, ignorante amigo vuestro, se os desea, tanto en nombre propio como del equipo que estamos en esta esta, vuestra casa, un muy Feliz año 2019. Que el año entrante os traiga fortuna, alegrías, riquezas y, en mi opinión lo más importante, felicidad a raudales. Asimismo, os pido que, en la medida de lo que podamos, intentemos hacer de este, un mundo mejor. Un fuerte abrazo para todos…

Cifrado de datos en tránsito

Cuando se transmiten datos confidenciales, en cualquier nivel de su aplicación o arquitectura de red, debemos considerar el cifrado en tránsito de algún tipo. TLS es con mucho, el modelo más común y ampliamente soportado utilizado por las aplicaciones web para el cifrado en tránsito. A pesar de las deficiencias publicadas en implementaciones específicas (por ejemplo, Heartbleed), sigue siendo el método recomendado para la implementación del cifrado de capa de transporte.

Cifrado de datos en Rest

El almacenamiento criptográfico es bastante difícil de construir con seguridad. Es crítico clasificar los datos en su sistema y determinar que los datos necesitan ser encriptados, como la necesidad de encriptar las tarjetas de crédito según el estándar de conformidad PCI-DSS. Además, cada vez que empiece a construir sus propias funciones criptográficas de bajo nivel por su cuenta, asegúremonos de contar con la ayuda de un experto en el caso de que no tener nosotros esos conocimientos. En lugar de crear funciones criptográficas desde cero, recomendamos encarecidamente utilizar bibliotecas abiertas y revisadas por pares, como el proyecto Google KeyCzar, Bouncy Castle y las funciones incluidas en los SDKs. Además, es necesario estar preparado para manejar los aspectos más difíciles de criptogramas aplicados, como por ejemplo la gestión de claves, el diseño de arquitectura criptográfica general, así como los problemas de nivelación y confianza en software complejo.

Una debilidad común en el cifrado de datos en reposo es utilizar una clave inadecuada o almacenar la clave junto con los datos cifrados (que básicamente es el equivalente criptográfico de dejar una clave debajo del felpudo). Las claves deben ser tratadas como secretas y sólo existen en el dispositivo en un estado transitorio, por ejemplo, introducidas por el usuario para que los datos puedan ser descifrados y luego borrados de la memoria. Otras alternativas incluyen el uso de hardware criptográfico especializado, como un módulo de seguridad de hardware (HSM) para la gestión de claves y el aislamiento de procesos criptográficos.

Implementar la protección en tránsito

Debemos asegurarnos de que los datos confidenciales o sensibles no sean expuestos accidentalmente durante el procesamiento. Puede ser más accesible en la memoria; o puede escribirse en ubicaciones temporales de almacenamiento o archivos de registro, donde un atacante podría leerlo.

Aplicación móvil: Almacenamiento local seguro

En el contexto de los dispositivos móviles, que se pierden o roban regularmente, el almacenamiento seguro de datos locales requiere técnicas adecuadas. Cuando una aplicación no implementa correctamente los mecanismos de almacenamiento, puede provocar fugas de información graves (ejemplo: credenciales de autenticación, token de acceso, etc.). Cuando se gestionan datos muy sensibles, el mejor camino es no guardar nunca esos datos en un dispositivo móvil, incluso utilizando métodos conocidos como un llavero iOS.

Almacenaje de passwords

El almacenamiento adecuado ayuda a evitar el robo, compromiso y uso malicioso de las credenciales. Los sistemas de información almacenan contraseñas y otras credenciales en una variedad de formularios protegidos. Las vulnerabilidades comunes permiten el robo de contraseñas protegidas a través de vectores de ataque como SQL Injection. Las contraseñas protegidas también se pueden robar de artefactos como registros, vertederos y copias de seguridad.

Esta guía específica protege contra el robo de credenciales almacenadas, pero la mayor parte de la guía apunta a prevenir el compromiso de credenciales. Es decir, esta guía ayuda a los diseños a resistirse a revelar las credenciales de los usuarios o a permitir el acceso al sistema en caso de que las amenazas roben información de credencial protegida. Para obtener más información y un tratamiento completo de este tema, consulte el Modelo de amenaza de almacenamiento seguro de contraseñas aquí

Utilice una salt criptográficamente fuerte específica de credencial

Una salt (En criptografía, la sal (también conocido como semilla) comprende bits aleatorios que se usan como una de las entradas en una función derivadora de claves. La otra entrada es habitualmente una contraseña. La salida de la función derivadora de claves se almacena como la versión cifrada de la contraseña. La sal también puede usarse como parte de una clave en un cifrado u otro algoritmo criptográfico. La función de derivación de claves generalmente usa una función hash. A veces se usa como sal el vector de inicialización, un valor generado previamente) es un valor aleatorio de longitud fija criptográficamente fuerte. Añada datos de credencial a la sal y utilícelos como entrada para una función de protección. Almacene el formulario protegido adjunto a la sal como se indica a continuación:

Sigamos estas prácticas para implementar adecuadamente sales específicas de credenciales:

  • Generemos una sal única al crear cada credencial almacenada (no sólo por usuario o sistema)
  • Utilicemos datos aleatorios criptográficamente fuertes
  • Si el almacenamiento lo permite, utilicemos una sal de 32 bytes o 64 bytes (el tamaño real depende de la función de protección)
  • La seguridad del esquema no depende de ocultar, partir u oscurecer la sal, nunca lo olvidemos.

Las salt (o semillas) sirven para dos propósitos:

1) evitar que la forma protegida revele dos credenciales idénticas y

2) aumentar la entropía alimentada para proteger la función sin depender de la complejidad de la credencial. Este segundo tiene como objetivo hacer que los ataques de búsqueda pre calculados sobre una credencial individual y los ataques basados en el tiempo sobre una población intratable.

Imponer una verificación inviable al atacante

La función utilizada para proteger las credenciales almacenadas debe equilibrar la verificación del atacante y el defensor. El defensor necesita un tiempo de respuesta aceptable para verificar las credenciales de los usuarios durante el uso máximo. Sin embargo, ¿el tiempo requerido para map <credential>? <protected form> debe permanecer más allá de las capacidades de hardware (GPU, FPGA) y técnica (basadas en diccionario, fuerza bruta, etc.) de las amenazas.

Aprovechemos una función adaptable unidireccional

Las funciones adaptables unidireccionales calculan una transformación unidireccional (irreversible). Cada función permite configurar el “factor de trabajo”. Los mecanismos subyacentes utilizados para lograr la irreversibilidad y gobernar los factores de trabajo (tales como el tiempo, el espacio y el paralelismo) varían entre las funciones y siguen sin tener importancia para esta discusión.

Seleccionemos:

  • Argon2 es el ganador del concurso de hashing de contraseñas y debe ser considerado como nuestra primera opción para nuevas aplicaciones.
  • PBKDF2 cuando se requiere la certificación FIPS o soporte empresarial en muchas plataformas.
  • scrypt donde es necesario resistir cualquier/todos los ataques acelerados por hardware, pero el soporte no lo es.
  • bcrypt donde no hay soporte para PBKDF2 o scrypt.

A continuación, se muestra un ejemplo de protección () pseudo-código:

return [salt] + pbkdf2([salt], [credential], c=10000);

Los desarrolladores seleccionan funciones adaptables de una sola dirección para implementar protect() porque estas funciones pueden configurarse para que cuesten (linealmente o exponencialmente) más que una función hash para ejecutar. Los defensores ajustan el factor trabajo para mantenerse al ritmo de las crecientes capacidades de hardware de las amenazas. Aquellos que implementan funciones adaptables de un solo sentido deben ajustar los factores de trabajo para impedir a los atacantes, sin que esto menoscabe al mismo tiempo una experiencia de usuario y escala aceptables para los usuarios.

Además, las funciones adaptables unidireccionales no impiden eficazmente la inversión de las credenciales comunes basadas en diccionarios (usuarios con contraseña’ password’), independientemente del tamaño de la población de usuarios o el uso de sal.

Factor trabajo

Puesto que los recursos deben considerarse normalmente limitados, una regla común para afinar el factor de trabajo (o coste) es hacer que protect () funcione lo más lento posible sin afectar la experiencia de los usuarios y sin aumentar la necesidad de hardware adicional sobre el presupuesto. Por lo tanto, si los casos de registro y autenticación aceptan protect() tardando hasta 1 segundo, podemos ajustar el costo para que le tome 1 segundo para ejecutarse en su hardware. De esta manera, no debería ser tan lento que sus usuarios se vean afectados, pero también debería afectar al intento de los atacantes tanto como sea posible.

Aunque recomiendamos un número mínimo de iteraciones para garantizar la seguridad de los datos, este valor cambia cada año a medida que la tecnología mejora. Un ejemplo del recuento de iteraciones elegido por una empresa bien conocida es el de las 10.000 iteraciones que Apple utiliza para sus contraseñas iTunes (utilizando PBKDF2. Sin embargo, es crítico entender que un solo factor de trabajo no se ajusta a todos los diseños. La experimentación es importante

Aprovechamiento Funciones clave

Las funciones clave, como los HMAC, calculan una transformación unidireccional (irreversible) utilizando una clave privada y una entrada determinada. Por ejemplo, los HMAC heredan propiedades de las funciones hash, incluida su velocidad, lo que permite una verificación casi instantánea. El tamaño de la clave impone requisitos de tamaño y/o espacios inviables al compromiso, incluso para credenciales comunes (contraseña =’ contraseña’). Diseñadores que protegen las credenciales almacenadas con funciones clave:

  • Utilicemos una única clave “para todo el sitio”.
  • Protejamos esta clave como cualquier clave privada utilizando las mejores prácticas.
  • Guardemos la clave fuera del almacén de credenciales (alias: no en la base de datos).
  • Generemos la clave utilizando datos pseudoaleatorios criptográficamente fuertes.
  • No nos preocupemos por el tamaño del bloque de salida (es decir, SHA-256 vs. SHA-512).

A continuación, se muestra un ejemplo de protección () pseudo-código:

return [salt] + HMAC-SHA-256([key], [salt] + [credential])

El mantenimiento de la mejora de la seguridad frente a (sólo) los sistemas con salt depende de una gestión adecuada de las claves.

Almacenamiento de contraseñas de diseño asumiendo un eventual compromiso

La frecuencia y facilidad con la que las amenazas roban credenciales protegidas exige un “diseño planteado para el fracaso“. Es decir, una vez detectado el robo, un esquema de almacenamiento de credenciales debe apoyar la operación continúa marcando los datos de credenciales como comprometidos. También es fundamental utilizar flujos de trabajo alternativos de validación de credenciales de la siguiente manera:

Proteger la cuenta del usuario

  • Invalidemos los “atajos” de autenticación al no permitir el inicio de sesión sin factores secundarios, preguntas secretas o alguna otra forma de autenticación fuerte.
  • Deshabilitemos los cambios en las cuentas de usuario, como la edición de preguntas secretas y los cambios en la configuración de multi-factor de la cuenta.

Cargar y utilizar un nuevo esquema de protección

  • Carguemos un nuevo y más fuerte esquema de protección de credenciales (consulte la siguiente sección sobre: Actualización de su solución de hashing de contraseñas existente).
  • Incluyamos la información de versión almacenada con el formulario.
  • Configurar bit’ contaminado’ /’ comprometido’ hasta que el usuario restablezca las credenciales.
  • Girar las teclas y/o ajustar los parámetros de la función de protección, como el factor de trabajo o la salt.
  • Número de versión del plan de incremento.

Cuando el usuario inicia sesión:

  • Validar credenciales basadas en la versión almacenada (antigua o nueva); si la versión comprometida más antigua sigue activa para el usuario, exija un segundo factor o respuestas secretas hasta que el nuevo método se implemente o active para ese usuario.
  • Solicitar al usuario el cambio de credencial, disculparse y realizar confirmación fuera de la banda.
  • Convertir las credenciales almacenadas en un nuevo esquema a medida que el usuario se conecta con éxito.

No limitemos el juego de caracteres y establezca longitudes máximas largas para las credenciales.

Algunos proyectos restringen:

  1. los tipos de caracteres especiales y
  2. la longitud de las credenciales aceptadas por los sistemas debido a su incapacidad para prevenir la inyección de SQL, scripting en varios sitios, la inyección de comandos y otras formas de ataques de inyección.

Estas restricciones, aunque bien intencionadas, facilitan ciertos ataques simples como la fuerza bruta, tengámoslo en cuenta.

No debemos permitir contraseñas cortas o sin longitudes y no aplicar restricciones de codificación o conjunto de caracteres a la entrada o almacenamiento de credenciales. Debemos continuar aplicando codificación, escape, enmascaramiento, omisión directa y otras mejores prácticas para eliminar los riesgos de la inyección.Una longitud de contraseña larga razonable es 160. Políticas de contraseñas muy largas pueden llevar a DOS en ciertas circunstancias

Prevención de vulnerabilidades

Decisión de Arquitectura

Se debe tomar una decisión de arquitectura para determinar el método apropiado para proteger los datos cuando se transmiten. Las opciones más comunes disponibles para las corporaciones son las Redes Privadas Virtuales (VPN) o un modelo SSL/TLS comúnmente utilizado por las aplicaciones web. El modelo seleccionado debe estar determinado por las necesidades empresariales de la organización en particular. Por ejemplo, una conexión VPN puede ser el mejor diseño para una asociación entre dos compañías que incluye el acceso mutuo a un servidor compartido sobre una variedad de protocolos. A la inversa, un Internet que se enfrenta a una aplicación web empresarial probablemente sería mejor servida por un modelo SSL/TLS.

El TLS es principalmente una defensa contra los ataques “Man in the middle”. Un Modelo de Amenaza TLS es aquel que comienza con la pregunta “¿Cuál es el impacto comercial de la capacidad de un atacante para observar, interceptar y manipular el tráfico entre el cliente y el servidor”?

Protección de la capa de transporte con SSL/TLS

Beneficios

El principal beneficio de la seguridad de la capa de transporte es la protección de los datos de las aplicaciones web contra la divulgación y modificación no autorizadas cuando se transmiten entre clientes (navegadores web) y el servidor de aplicaciones web, y entre el servidor de aplicaciones web y el back-end y otros componentes empresariales no basados en navegadores.

El componente de validación del servidor de TLS proporciona la autenticación del servidor al cliente. Si está configurado para requerir certificados del lado del cliente, TLS también puede jugar un papel en la autenticación del cliente al servidor. Sin embargo, no perdamos de vista que, en la práctica, los certificados del lado del cliente no se utilizan a menudo en lugar de los modelos de autenticación basados en nombre de usuario y contraseña para los clientes. TLS también proporciona dos beneficios adicionales que comúnmente se pasan por alto: la integridad garantiza y la prevención de repetición.

Un flujo de comunicación TLS contiene controles incorporados para evitar la manipulación de cualquier porción de los datos cifrados. Además, los controles también están incorporados para evitar que una secuencia capturada de datos TLS sea reproducida posteriormente.

Cabe señalar que TLS proporciona las garantías antes mencionadas a los datos durante la transmisión. TLS no ofrece ninguno de estos beneficios de seguridad a los datos que están en reposo. Por lo tanto, deben añadirse controles de seguridad adecuados para proteger los datos mientras están en reposo dentro de la aplicación o dentro de los almacenes de datos.

Usar TLS, ya que SSL ya no se considera utilizable por motivos de seguridad:

  • Todas las páginas deben ser servidas sobre HTTPS. Esto incluye css, scripts, imágenes, peticiones AJAX, datos POST y datos de terceros. De lo contrario, se crea un vector para los ataques del hombre en el medio.
  • No basta con proteger las páginas autenticadas con HTTPS, no es suficiente.
  • Una vez que hay una petición en HTTP, es posible realizar ataques man-in-the-middle, ya que los atacantes pueden impedir que los usuarios lleguen a las páginas protegidas.
  • El encabezado de seguridad de transporte HTTP Strict Transport Security Header debe ser utilizado y precargado en los navegadores. Esto indicará a los navegadores compatibles que sólo usen HTTPS, aunque se solicite el uso de HTTP.
  • Las cookies deben estar marcadas como seguras.

Requisitos Básicos Uso TLS

Los requisitos básicos para utilizar TLS son:

  • Acceso a una infraestructura de clave pública (PKI) para obtener certificados,
  • Acceso a un directorio o a un servidor de respuesta de Protocolo de estado de certificado en línea (OCSP) para comprobar el estado de revocación del certificado.
  • Acuerdo/capacidad para soportar una configuración mínima de las versiones de protocolo y opciones de protocolo para cada versión.

SSL vs. TLS

Los términos Secure Socket Layer (SSL) y Transport Layer Security (TLS) se utilizan a menudo indistintamente. De hecho, SSL v3.1 es equivalente a TLS v1.0. Sin embargo, diferentes versiones de SSL y TLS son soportadas por navegadores web modernos y por la mayoría de las plataformas y frameworks web modernos. Para los propósitos de esta hoja de trucos nos referiremos a la tecnología genéricamente como TLS.

Cuándo usar un criptomódulo validado FIPS 140-2

Si nuestra aplicación web puede ser el objetivo de determinados atacantes (un modelo de amenaza común para las aplicaciones accesibles a Internet que manejan datos confidenciales), se recomienda encarecidamente siempre que sea posible utilizar los servicios TLS que proporcionan los criptomódulos validados por FIPS 140-2.

Un criptomódulo, ya sea una biblioteca de software o un dispositivo de hardware, consta básicamente de tres partes:

  • Componentes que implementan algoritmos criptográficos (algoritmos simétricos y asimétricos, algoritmos hash, algoritmos generadores de números aleatorios y algoritmos de código de autenticación de mensajes).
  • Componentes que llaman y gestionan funciones criptográficas (las entradas y salidas incluyen claves criptográficas y los denominados parámetros de seguridad críticos).
  • Un contenedor físico alrededor de los componentes que implementan algoritmos criptográficos y los componentes que llaman y gestionan las funciones criptográficas.

La seguridad de un criptomódulo y sus servicios (y las aplicaciones web que lo llaman criptomódulo) dependen de la correcta implementación e integración de cada una de estas tres partes. Además, el criptomódulo debe utilizarse y accederse de forma segura. El incluye consideración para:

  • Llamada y gestión de funciones criptográficas.
  • Manejo seguro de entradas y salidas.
  • Garantizar la construcción segura del contenedor físico alrededor de los componentes.

Para aprovechar los beneficios de TLS es importante utilizar un servicio TLS (por ejemplo biblioteca, marco web, servidor de aplicaciones web) que ha sido validado por FIPS 140-2. Para poder aprovechar los beneficios de TLS, es importante utilizar un servicio TLS (por ejemplo biblioteca, marco web, servidor de aplicaciones web) que ha sido validado por FIPS 140-2. Además, el criptomódulo debe ser instalado, configurado y operado en un modo aprobado o permitido para proporcionar un alto grado de certeza de que el criptomódulo validado FIPS 140-2 está proporcionando los servicios de seguridad esperados de la manera esperada.

Si el sistema está legalmente obligado a utilizar el cifrado FIPS 140-2 (por ejemplo, propiedad u operado por o en nombre del gobierno de los EE. UU.), se debe utilizar TLS y desactivar SSL. Encontrará más información sobre el uso de TLS para proteger datos altamente confidenciales contra determinados atacantes en las Directrices SP800-52 para la selección y el uso de implementaciones de seguridad de la capa de transporte (TLS).

P.D: ¡Ah! Que se me olvidaba, @fpalenzuela me ha dicho que el año que viene va a ser el año de Linux en el escritorio, que esta convencido de ello y que se pasa a Trisquel si o si… Ahí lo dejo 😉

4 respuesta a “Nociones breves acerca de la necesidad de la protección de los datos (o la trilogía de como ser un desarrollador cuqui sin llamarse Borja Mari…)”

  1. Querido amigo, este post es cremita. Mis disculpas por no haberlo visto antes.

    De hecho, voy a usarlo como referencia en una presentacion que estoy haciendo de desarrollo seguro la semana que viene en mi nuevo trabajo. Si, ya tengo jajaja

    Besis

    1. ¡Hombre, cuanto bueno nos honra por aquí! La alegría de saber de ti, solo se ve superada por la satisfacción de saber que encontraste trabajo. Tu jefe aún no sabe la increíble suerte que tiene de poder contar con alguien de tu valía profesional y calidad humana. Mis más sinceras felicitaciones para ambos, en breve nos vemos amigo en tu nuevo hogar. Un fuerte abrazo

Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *

Este sitio usa Akismet para reducir el spam. Aprende cómo se procesan los datos de tus comentarios.