Seguridad

Seguridad¶

Cualquier sistema o recurso informático, ya sea un servidor, un sitio, un dato, una aplicación o una página web, debe protegerse contra accesos indebidos. Los siguientes son los requisitos de seguridad deseables de cualquier sistema informático:

Confidencialidad: Asegurar que sólo los usuarios autorizados pueden leer (tener acceso para lectura) los recursos del sistema.
Integridad: Asegurar que sólo los usuarios autorizados pueden modificar (tener acceso para escritura) los recursos del sistema.
Disponibilidad: Asegurar que aquellos (y solo aquellos) usuarios que estén autorizados para el acceso (ya sea para lectura o para escritura) a los recursos de un sistema pueden hacerlo efectivamente.

Amenazas¶

Las amenazas más comunes a los requisitos CID (Confidencialidad, Integridad, Disponibilidad) o CIA en inglés (Confidentiality, Integrity, Availability) se pueden clasificar en función de los factores que se ve comprometido:

Intercepción
Modificación
Interrupción
Fabricación

Clases de amenazas a la seguridad

Leer el apartado Naturaleza de las amenazas del monográfico Introducción a la seguridad informática - Amenazas.

Seguridad en un sistema abierto¶

La World Wide Web es un sistema abierto al que cualquier persona o agente puede acceder. Como tal, hay que proteger todos los sistemas y recursos informáticos que existen en la Web. Los datos, las páginas y las aplicaciones web son recursos a los que puede acceder cualquiera, no siempre con buenos propósitos.

Las siguientes son algunas de las características más habituales de la seguridad en un sistema abierto:

Autenticación: Identificación de las entidades participantes en una comunicación y del origen de los datos intervinientes en la misma.
Control de acceso: Protección contra el uso no autorizado de los recursos accesibles. Es aplicable a varios tipo de acceso a recursos (para lectura, para escritura, para borrado, para ejecución, etc.)
Confidencialidad de recursos: Protección contra la revelación no autorizada de determinados recursos del sistema (datos e información).
Integridad de recursos: Protección contra la modificación, inserción, borrado o repetición no autorizadas de los recursos del sistema (datos e información).
No repudio: Proporcionar al receptor de una comunicación una prueba del origen de los datos recibidos; sirve para proteger contra intentos del emisor de denegar en falso haberlos enviado. Asimismo, proporcionar al emisor una prueba de entrega de los datos en una comunicación; sirve para proteger contra cualquier intento del receptor de denegar en falso haberlos recibido.

Autenticación¶

Los requisitos CID de seguridad parten de la base de que hay que poder identificar a cada usuario que intenta realizar un acceso.

La identificación o autenticación se lleva a cabo por una serie de mecanismos. Normalmente se usa alguno de estos factores para autenticar y así determinar si se tiene o no acceso a un recurso:

Algo que sabes: por ejemplo, un PIN, una contraseña;
Algo que tienes: por ejemplo, una tarjeta, una credencial, un móvil;
Algo que eres: por ejemplo, una huella dactilar, un escáner ocular o algún rasgo biométrico;
Algo que haces: por ejemplo, el reconocimiento de voz, la firma manuscrita o la cadencia del paso al caminar.

A veces se usan combinaciones de varios de estos factores para identificar si un usuario puede acceder a un sistema. Es muy común usar autenticación de doble factor. Por ejemplo, muchos servicios en la Web (Google, Amazon, Apple iCloud, muchos bancos) solicitan una contraseña (algo que sabes) y un código enviado al teléfono móvil (algo que tienes) para poder acceder al sistema o para realizar una operación (como una transferencia de fondos).

Control de acceso¶

El control de acceso es la capacidad de un sistema para permitir o denegar el uso de un recurso. El control de acceso decide qué sujetos están autorizados (y quiénes no) a realizar ciertas operaciones sobre un determinado recurso.

¿Cuánto dura el permiso?

Una vez que un usuario se ha autenticado y se le ha dado permiso para acceso a los recursos de un sistema, ¿cuánto dura dicho permiso? ¿Para siempre? ¿Mientras está dentro del sistema? ¿Durante un tiempo?

Sesiones¶

En informática, una sesión es un intercambio de información interactivo y limitado en el tiempo entre dos o más dispositivos de comunicación, o entre un ordenador y usuario.

Es limitado en el tiempo porque una sesión se establece en un cierto momento y finaliza poco después.
Es interactivo porque una sesión de comunicación establecida suele implicar más de un mensaje enviado y recibido en cada dirección.

En general, la sesión define el periodo de tiempo durante el que un usuario puede seguir accediendo a un recurso tras haber obtenido un permiso inicial de acceso.

Si se cierra la sesión, habitualmente (pero no siempre) se pierde el acceso al recurso y hay que volver a iniciar otra sesión, sometiéndose de nuevo un control de acceso, para volver a acceder.

Estado de la sesión¶

Una sesión es típicamente (pero no siempre) con estado. Esto significa que al menos una de las partes comunicantes necesita guardar información sobre el estado de la sesión e información sobre la misma para ser capaz de comunicarse con la otra.

En su versión más simple, el emisor y receptor se ponen de acuerdo en un identificador, que forma parte del estado. El identificador de sesión quedará asociado a todos los mensajes que intercambien, para poder saber a qué sesión se refiere un mensaje recibido.
En una versión más compleja, el estado de la sesión incluye información sobre si estamos esperando una respuesta o no, si hemos recibido correctamente y en orden todos los mensajes, etc.

En cambio, algunas comunicaciones pueden ser sin estado. En este caso la comunicación consta de peticiones y respuestas independientes, no siendo posible correlacionar, como pertenecientes a una misma sesión, un par de mensajes petición↔respuesta con otro par de mensajes ocurridos posteriormente.

Para poder correlacionar dos parejas de mensajes como pertenecientes a un mismo diálogo o conversación entre dos personas o dispositivos, es necesario disponer de un código identificativo (id) de sesión, conocido por ambas partes. Cuando ambas partes empiezan el diálogo, se ponen de acuerdo en crear un id de sesión y lo asocian a todos los mensajes individuales que intercambian. Así se puede establecer una sesión con estado a pesar de que la comunicación sea sin estado.

Cookies¶

¿Qué son las famosas cookies en Internet y la Web?

En principio, una cookie no es más que un identificativo de sesión, necesario porque HTTP es un protocolo de comunicación sin estado y que no requiere autenticación para poder iniciar una sesión:

Los mensajes HTTP intercambiados por navegadores y servidores para traer y llevar el contenido de una página web entre ambos no podrían correlacionarse como pertenecientes a una misma conversación, ni siquiera de una sesión a otra del mismo usuario.
En HTTP no es obligatorio identificarse con usuario y contraseña para empezar a consultar páginas web (es decir, los recursos a proteger) de un servidor.

¿Para qué sirven las cookies?

Si un usuario no necesita autenticarse para consultar la mayoría de páginas web, ¿cómo consigue una aplicación web reconocer a un mismo usuario cuando éste se conecta en distintas ocasiones?

¿Qué es una cookie?

Ver el siguiente video What is a cookie

El problema de las cookies es que han dejado de ser simples identificadores de sesión para guardar algo más de información que debería ser confidencial o privada: las páginas visitadas, las preferencias mostradas, las compras realizadas, etc. Es decir, son una amenaza a la privacidad. Por ello, la normativa actual en muchos países obliga a dar un consentimiento explícito para el uso de cookies en las páginas web visitadas.

Claves y contraseñas¶

El mecanismo más habitual para identificarse al acceder a un sistema es el de la pareja usuario-contraseña.

Contraseñas robustas

Leer el artículo del INCIBE sobre el Día Mundial de las Contraseñas: ¿Aún utilizas 123456?

Para averiguar el por qué de elegir contraseñas robustas, hay que analizar cómo funciona el control de acceso por usuario y contraseña.

Cómo almacenan las aplicaciones web nuestras contraseñas?

Cuando definimos un usuario y una contraseña para acceder a una aplicación web, ¿la aplicación la almacena esta información tal cual?

Dicho de otro modo, ¿la contraseña se almacena con su texto en claro (es decir, sin cifrar) para compararla en un futuro con la que proporcionemos cuando queramos acceder?

La aplicación web no debería hacer esto y no debería tener idea de cuál es la contraseña real.

De cara a la autenticación, los sistemas y aplicaciones almacenan un pequeño código abreviado (llamado hash o digest), calculado a partir de la contraseña en claro aplicando un algoritmo criptográfico llamado de hashing. Lo más notable del algoritmo de hashing es que:

Si aplicamos el algoritmo sobre el mismo texto original, se obtiene siempre el mismo digest.
No tiene operación inversa, es decir, es imposible obtener el texto original de la contraseña a partir del digest;
Es muy poco probable (casi imposible) que el digest pueda generarse a partir de cualquier otro texto en claro, aunque sean pequeñas variaciones del original;

Cuando el usuario acceda de nuevo, deberá proporcionar exactamente la misma contraseña para que, tras aplicarle el algoritmo de hashing, el sistema pueda decidir si la contraseña es o no correcta, aún sin conocer su texto en claro. Lo único que conoce es el digest o hash de la contraseña, que compara con el almacenado para decidir si debe autorizar el acceso o no.

Por ejemplo, si alguna vez olvidas tu contraseña de algún servicio online, probablemente tengas que resetearla. Cuando se restablece una contraseña, por lo general no recibes una nueva con texto en claro. Eso es debido a que los servicios online no deben almacenar el texto de las contraseñas tal cual. Si recibes una contraseña con texto en claro, quiere decir que el servicio online no está aplicando unas medidas de seguridad adecuadas.

El problema de usar contraseñas demasiado cortas o demasiado simples es que el valor hash o digest de ese tipo de contraseñas es ampliamente conocido. Incluso hay bases de datos donde se publican hashes calculados a partir de contraseñas típicas ("1234567", nombres de pila, etc.)

Contraseñas populares

Según un análisis realizado por el Centro de Ciberseguridad Nacional (NCSC) de Reino Unido, de las 100.000 contraseñas más comunes obtenidas de diferentes fugas de información, más de 40 millones de usuarios utilizan contraseñas que un ciberdelincuente podría obtener en tan solo un segundo.

Leer el artículo sobre el informe del NCSC sobre las contraseñas más populares de 2019

Tokens¶

Cuando queremos acceder al servicio que nos da una aplicación web directamente, suele bastar con usuario y contraseña. Pero, ¿qué sucede si queremos autorizar a una aplicación web para que acceda a un servicio en nuestro nombre? ¿Debemos pasarle el usuario y la contraseña? No parece una forma demasiado segura, pues estas credenciales son individuales y no deben ser transferibles.

¿Qué haces para recoger un paquete en correos si no puedes ir?

Pasar nuestro usuario y contraseña a alguien es como prestar nuestro DNI físicamente a alguien para que vaya a recogernos un paquete a correos. ¿No podrá mala cara el funcionario, o incluso no permitirá su recogida? Normalmente, se nos pide una copia del DNI y una autorización firmada para poder recogerlo. Lo mismo sucede cuando queremos encargar a una aplicación web que haga algo de nuestra parte.

No es buena práctica pasar el usuario y la contraseña tal cual. En su lugar, se suele generar una especie de autorización firmada que toma la forma de un token generado específicamente para nosotros y que el sistema al que queremos acceder marca como autorizado.

Ese token es también un hash generado por un algoritmo criptográfico. En este caso, el código hash no es generado a partir de la contraseña, sino que es simplemente un código único generado aleatoriamente. Lo de unico significa que muy poco probable matemáticamente que se genere el mismo código en cualquier otra ocasión que se le pida. Este token autorizado es el que le pasaremos al servicio que queremos que actúe en nuestro lugar.

Códigos QR¶

Un código QR (Quick Response code – Código de Respuesta Rápida) es una matriz bidimensional de puntos que contiene información que puede leerse desde dispositivos móviles. Se caracteriza por tener tres cuadrados en las esquinas, que permiten al lector posicionar el código. Es un estándar internacional (ISO/IEC18004). Es de licencia abierta y sus derechos de patente no se ejercen.

Un código QR lleva codificada información de muchos tipos, por lo que puede servir para diferentes propósito:

Texto: Se muestra el texto al leer el código.
URL: Propociona la dirección de acceso a cualquier recurso de internet:
vCard: Incluye los datos de contacto de una tarjeta de visita vCard.
SMS: Reliza el envío de un SMS con texto y destino incluidos.
Llamada de voz: Marca el nº de teléfono incluido.
E-mail: Envía un correo electrónico a un destinatario.

Una última finalidad de un código QR es para autenticación, cuando lleva codificado un token o hash autorizado para pasar un control de acceso a un recurso o realizar una cierta operación.