security-monkey-netflix

Security Monkey: Controla la seguridad de AWS con Netflix (parte 1)

Supongo que todos conocéis Netflix a estas alturas, el servicio VOD con suscripción mensual que aterrizó en España hace unos meses y ya es todo un éxito.

Pero, además de ser una forma estupenda de ver películas y series, puede ofrecernos mucho que aprender gracias a lo que algunos (yo no :D) llaman pornografía tecnológica.

Netflix es una de esas empresas que se rodea de los mejores ingenieros para poder ofrecer un servicio con calidad por encima de lo normal. En ese sentido, leer de forma regular «The Netflix Tech Blog» es altamente recomendable.

 

Aprendiendo de los mejores

Que profesionales tan altamente cualificados como los que trabajan en Neflix dediquen una parte de su tiempo a contarnos cómo hacen las cosas, es algo de agradecer. Vivimos en un mundo en el que estamos obligados a aprender de forma contínua y este tipo de lecturas nos abren la mente a nuevas formas de hacer las cosas.

Puedes encontrar temas tan interesantes como:

Y sobre todo, en general de elementos de Amazon WS (unos servicios con los que suelo trabajar tal y como os conté en Controla lo que hacen tus usuarios con Amazon WS IAM (parte 1) y Controla lo que hacen tus usuarios con Amazon WS IAM (parte 2)).

aws-summit-1

 

Security Monkey

Revisando esto, me he encontrado con una solución desarrollada por el equipo Netflix que tiene por objetivo monitorizar y analizar la seguridad de los servicios de AWS.

Se trata de un desarrollo propio que ofrecen como open source y que nos permite monitorizar la configuración de los servicios EC2, RDS, S3 e IAM. Cualquier cambio que se realice sobre ellos quedará registrado para que tengamos el control de todo lo que sucede.

Está pensada para correr sobre una máquina Linux y almacenar la información en una PostgreSQL. A nivel tecnológico está escrita en Python utilizando el framework Flask, utilizando datos JSON servidos mediante una API REST.

Casos de uso típicos serían:

  • Visualización de cambios históricos de un elemento (como los cambios en grupos de seguridad).
  • Auditorías de configuraciones incorrectas (como permisos en buckets S3).

Para conseguir esto, Security Monkey cuenta con tres componentes principales:

  • Watcher, es el encargado de observar nuestra cuenta para detectar cambios. Cuando eso ocurre, se almacena esa información en la base de datos interna.
  • Notifier, es el encargado de avisarnos cuando se produce un evento que podemos personalizar.
  • Auditor, es el encargado de realizar pruebas y revisiones sobre los elementos, reglas y políticas. Podemos definir aquello que no queremos que ocurra para que salte una alarma si se encuentra (como grupos de seguridad con puertos abiertos al mundo).

Una vez lo tengamos funcionando podremos acceder mediante su interfaz web, configurar los elementos que queremos monitorizar y ver todo en detalle.

 

¿Te ha gustado tanto como a mi? Entonces descarga el proyecto desde su repositorio y coméntanos qué tal tu experiencia. Yo lo haré en un post en el que os mostraré el proceso de instalación, configuración y uso. De momento, esto es todo, espero que os esté resultando interesante.

Como siempre digo, si ves algún error, no estás de acuerdo con lo que cuento o quieres hacer alguna aportación, no dudes en pasarte por los comentarios.

Controla lo que hacen tus usuarios con Amazon WS IAM (parte 2)

En la primera parte de esta serie de post relativos a la gestión de usuarios (IAM) en Amazon WS, estuvimos conversando sobre la forma en la que conceder permisos de forma ordenada y sencilla, así como algunos consejos para tener el control de todo lo que ocurre. Si no lo recuerdas, no dudes en echarle un vistazo antes de seguir.

Algo realmente importante en este panel IAM es el control sobre la cuenta root. No se aconseja utilizar dicha cuenta y Amazon nos anima en el panel de control a activar autenticación multifactor (MFA).

aws-iam-2-1

Panel de control de Amazon WS IAM

 

Como se puede ver en este ejemplo, uno de los checks importantes de seguridad es activar ese MFA. El motivo es sencillo, añadir una capa extra de seguridad al acceso con el usuario que tiene capacidad para hacer cualquier cosa, incluso eliminar la propia cuenta.

De esta forma, para entrar como root, se necesitará la contraseña (algo que el usuario sabe) y otro elemento que ahora veremos (algo que el usuario tiene). En mi caso, ese elemento es un código temporal que puede ser gestionado de diferentes formas:

aws-iam-2-2

Opciones MFA en Amazon WS

 

Básicamente, podemos optar por soluciones software o hardware. En mi caso particular, estoy utilizando la primera mediante apps para móviles. ¿El motivo? Hoy en día todo el mundo tiene smartphone, todos lo llevan siempre a mano y casi todos (en esto parece que la concienciación ha servido) tienen un patrón de bloqueo. Esto hace que «lo que el usuario tiene» esté mejor controlado que un dispositivo o tarjeta que sólo usa para acceso puntual.

De esta forma, si alguien pierde el teléfono puede avisar de inmediato para que su usuario sea puesto en cuarentena hasta que se renueven tanto la contraseña como el sistema mfa.

Las opciones de apps son estas:

aws-iam-2-3

Apps MFA para móviles

 

Por utilizar siempre la misma, recomiendo Google Authenticator para Android o iOS. Sólo tenemos que acceder a la pestaña «Security Credentials» del usuario y pulsar sobre la opción «Manage MFA Device».

aws-iam-2-4

 

Al seleccionarlo, se inicia el proceso. En nuestro caso, seleccionamos dispositivo virtual (app para móvil):

aws-iam-2-5

 

Únicamente tendríamos que arrancar la aplicación y escanear el qr que aparece en pantalla. Tras hacerlo, se nos piden dos códigos consecutivos para comprobar que todo funciona correctamente y listo.

aws-iam-2-6

 

La próxima vez que entremos en el panel de control de Amazon WS con este usuario, se nos pedirá un código que podremos consultar en nuestra app.

aws-iam-2-7

 

De esta forma, los pasos recomendables para la gestión de usuarios en Amazon WS IAM se podrían resumir en:

  1. Desde la cuenta root, crear un usuario para administración.
  2. Activar MFA en root y admin.
  3. Desde admin, gestionar usuarios, grupos y políticas.

Por supuesto, recuerda que el MFA también puede ser activado para el resto de usuarios. Al principio se mostrarán reticentes a utilizarlo, pero ya sabes que concienciar y hacer entender que ciertas medidas son necesarias para tratar de asegurar los activos de la empresa es parte fundamental de nuestro trabajo.

 

De momento, esto es todo, espero que os esté resultando interesante. Como siempre digo, si ves algún error, no estás de acuerdo con lo que cuento o quieres hacer alguna aportación, no dudes en pasarte por los comentarios.

Controla lo que hacen tus usuarios con Amazon WS IAM (parte 1)

En proyectos pasados y actuales he tenido que lidiar con los servicios cloud de Amazon, los conocidos como Amazon Web Services. Para los que no los conozcan, son un conjunto de servicios de computación, almacenamiento, base de datos, redes, análisis… que permiten montar infraestructuras complejas, eficientes y escalablas a precios muy competitivos (se paga por uso).

En un principio me tocó montar la red, servidores, servicios y bases de datos. Ahora ando desde otro punto de vista, el de tratar de asegurar la infraestructura para que la continuidad de negocio de mi trabajo actual no se vea comprometida. La puerta de entrada son los usuarios y de eso vamos a hablar hoy.

 

Entendiendo Amazon WS IAM

Para gestionar el acceso a los recursos, AWS cuenta con un servicio llamada IAM (Identity & Access Management) que permite gestionar el acceso a los recursos en base a diferentes identidades:

Usuarios: es una entidad individual, una persona que utiliza recursos. Cuando creamos un usuario, le podemos dar acceso a la consola de administración o a la api para que pueda interactuar con aquello que deseemos de AWS mediante políticas de uso.

Grupos: se utilizan para agrupar usuarios que tienen características similares y, por tanto, permisos similares. Normalmente se usan para crear departamentos en los que todos los usuarios tienen que tener acceso a los mismo recursos. Editar, añadir o eliminar una política al grupo, afecta inmediatamente a todos los usuarios del mismo.

Roles: son parecidos a los usuarios, pero de forma inpersonal. Son permisos que se conceden para llevar a cabo determinadas tareas puntuales. Se suelen usar para asignar a máquinas o procesos que se lanzan de forma automática o incluso aquellas que se lanzan de forma manual sin importar el usuario que lo hace (no es el usuario el que tiene los premisos, es el popio proceso).

 

¿Cómo indico qué se puede o no hacer?

Para eso están las policies, que son reglas que se aplican para cada servicio y que pueden contener todo tipo de detalle para hacerlas completamente a medida. Una policy tiene un aspecto similar a esto:

{
   "Version": "2012-10-17",
   "Statement": [{
      "Effect": "Allow",
      "Action": "ec2:Describe*",
      "Resource": "*"
    }
   ]
}

Tener cierto control y destreza a la hora de escribir estas policies es complicado, por eso Amazon nos pone a mano dos recursos interesantes:

  • AWS Policy Generator: una web en la que podemos ver todas las opciones que hay para cada servicio e incluso generar el fichero para hacer copy-paste.
aws-policy-generator

Web para generar policies de AWS.

 

  • Herramienta interna de simulación: desde la consola de administración de IAM podemos hacer una simulación de la policy que realizará una prueba sobre los recursos y acciones que definamos.
aws-simulate-policy1

Enlace para simular policy concreta

 

aws-simulate-policy2

Pantalla del simulador de policies

 

Asignación de policies

A la hora de aplicarlas sobre un usuario o grupo, podemos optar por hacerlo de dos formas:

  • Managed: podemos verlo como un policies que tenemos almacenadas y que asignamos con intención de que sea algo permanente (aunque, por supuesto, podemos revocar en cualquier momento).
  • Inline: es algo así como permisos temporales que se asignan con la intención de que sea algo puntual, ya sea por la persona o grupo que lo recibe o por el tipo de permiso que se concede.

 

¿Vemos un ejemplo?

Con todo esto, una posible situación sería asignar grupos por departamento y entorno de desarrollo, asignando las policies necesarias para cada zona concreta. Por ejemplo:

  • Departamento1-DEV: policies para usuarios del departamento1 con acceso a recursos de desarrollo.
  • Departamento1-PRE: policies para usuarios del departamento1 con acceso a recursos de preproducción.
  • Departamento1-PRO: policies para usuarios del departamento1 con acceso a recursos de producción.

Puesto que un usuario puede pertenecer a varios grupos, no habría problema en asignar a «Usuario1» a los grupos «DEV» y «PRE» del «Departamento1».

 

Control casero

Cuando todo esto empieza a crecer, utilizo un pequeño script que me lista todos los usuarios, así como las políticas que tiene asignadas como grupo o individualmente. Me sirve para exportar rápidamente esa información y poder ver en papel la foto actual de los permisos. Si utilizas la consola, tienes que entrar uno a uno y es un poco coñazo.

Lo único que hago es tirar consultas sobre la API para mostrar, de forma ordenada, la información que necesito.

##########################################################################################
#
# File: iam-list-users-policies.py
# Author: Cristobal Espinosa
# 
# https://boto3.readthedocs.org/en/latest/reference/services/index.html
#
##########################################################################################

# Imports ################################################################################
import boto3
from colorama import init, Fore, Style
##########################################################################################

# Initial values #########################################################################
init(autoreset=True)

step = False # Set as True to step by step view
##########################################################################################

print 
print Fore.GREEN + '-- IAM POLICIES CONTROL'
print Fore.GREEN + '----------------------------------------------------------------------------------'
print 

client = boto3.client('iam')

user_list = client.list_users()

# List users
for user in user_list['Users']:
    print Fore.YELLOW + '[**] ' + Fore.WHITE + user['UserName'] + ':'
    
    # List user inline policies
    print Fore.YELLOW + '\t[*] ' + Fore.WHITE + 'User inline policies:'
    user_policies = client.list_user_policies(UserName = user['UserName'])
        
    for policy in user_policies['PolicyNames']: 
        print '\t\t- ' + policy
    
    print    
    
    # List user managed policies
    print Fore.YELLOW + '\t[*] ' + Fore.WHITE + 'User managed policies:'
    user_policies = client.list_attached_user_policies(UserName = user['UserName'])
        
    for policy in user_policies['AttachedPolicies']: 
        print '\t\t- ' + policy['PolicyName']
    
    print

    # Get user groups    
    user_groups = client.list_groups_for_user(UserName = user['UserName'])

    print Fore.YELLOW + '\t[*] ' + Fore.WHITE + 'User groups and associated policies:'
    for group in user_groups['Groups']:
        
        group_policies = client.list_attached_group_policies(GroupName = group['GroupName'])
                        
        for group_policy in group_policies['AttachedPolicies']:
            print '\t\t- [' + group['GroupName'] + '] -> ' + group_policy['PolicyName']
    
        print

    print Fore.GREEN + '----------------------------------------------------------------------------------'
    print  
    
    if step: 
        raw_input("Press Enter to continue...")  
        print

Me gustaría trabajar en ampliar este script para que sea capaz de avisarme de cambios tanto en policies como en el contenido de las mismas, de forma que si un usuario «obtiene cambios fuera de control», pueda enterarme lo antes posible.

El resultado de este código es algo así:

aws-policy-script

Resultados del primer usuario

Lo que podéis ver aquí es el modo paso a paso (step = True) con los resultados del primer usuario (el nombre es lo que hay borrado junto a [**]). Se ve rápidamente que no tiene policies de tipo inline o managed y que, todo lo que tiene, le llega por pertenecer a dos grupos del mismo departamento y diferente entorno (DEV y PRE). Las policies asociadas a cada grupo aparecen a la derecha del mismo.

Como véis, un script muy sencillo, pero que me permite exportar rápidamente la información que necesito para verificar si algún usuario tiene permisos que no debe o pertenece a algún grupo equivocado.

 

De momento, esto es todo, en la continuación de esta entrada hablaremos del usuario root y de la autenticación con segundo factor. Espero que os esté resultando interesante y, como siempre digo, si ves algún error, no estás de acuerdo con lo que cuento o quieres hacer alguna aportación, no dudes en pasarte por los comentarios.

seguridad_pymes

5 consejos básicos de seguridad para PYMES sin dinero

La tecnología es ya algo que forma parte de nuestro día a día tanto a nivel personal como empresarial. Mi hija maneja el smartphone y la tablet con soltura (mucho mejor que sus abuelos), algo extensible a la mayoría de personas menores de 40 años.

En el mundo de hoy es impensable una empresa u organización que no tenga una fuerte base tecnológica, estemos hablando de base de datos de clientes, soluciones ERP o una simple (o compleja) página web.

Si echamos un vistazo a la situación actual es España, nos encontramos con que la inmensa mayoría de las empresas que nos rodean tienen menos de 250 trabajadores, lo que se conoce como PYME (Pequeña Y Mediana Empresa):

pymes

En este escenario podemos ahondar un poco más para darnos cuenta de que el uso de la tecnología es básico en este tipo de empresas:

uso_tecnologia

Sin embargo, cuando nos acercamos a evaluar las medidas de seguridad, planes de contingencia o de continuidad de negocio vemos con poco asombro (lamentablemente) que la situación es precaria.

planes de seguridad

Está claro que hay que invertir en seguridad

Desde nuestro punto de vista no hay más que ver los números para darse cuenta de que no se puede tener todo (o gran parte) del negocio sobre elementos tecnológicos y no tener un plan o medidas de seguridad que nos permitan tener cierto control sobre nuestra actividad habitual.

Sin embargo, las PYMEs en general no están demasiado concienciadas de este problema y suelen ver con cierto malestar las propuestas de, lo que consideran, un gasto absurdo en seguridad.

Convencer a este sector es todo un reto para los que nos movemos en este mundo, yo me he encontrado con esta situación en no pocas ocasiones y es algo muy complicado de abordar.

 

Las PYMEs sin dinero

Pero también hay que entender que los servicios profesionales en seguridad son caros y que muchas de estas empresas prefieren arriesgarse antes que afrontar el coste de un trabajo serio y profesional que les permita mantener su entorno dentro de unos límites aceptables de seguridad.

Si trabajas en alguna de estas empresas y tienes un rol técnico, si eres el responsable de sistemas, trabajas con la web o simplemente quieres aportar tu granito de arena a concienciar a tus compañeros y te encuentras en algunas de las PYMEs sin dinero (para invertir en seguridad), te quiero aportar cinco sencillos consejos para que la situación de tu empresa sea un poco mejor. Pero antes, para que entiendas lo importante que es esto, no estaría mal que supieras que…

 

Los “malos” ya no son lo que eran

Hace tiempo nos vendían la imagen del hacker malo como alguien encerrado en un cuarto rodeado de cables, generalmente a oscuras, con poca vida social y los ojos rojos de no dormir…

hacker_malo

dummies

 

Hoy en día la cosa ha cambiado y cualquiera que tenga un poco de interés por aprender puede hacerse con un manual o realizar una simple búsqueda en Google que le indique paso por paso qué tiene que hacer para fastidiar a la empresa de la competencia.

maldadPero aún hay más, si estás interesado pero te puede la pereza, sólo tienes que dar un par de vueltas por la deep web o hasta Youtube para encontrar alguien que lo haga por ti a cambio de unos cuantos bitcoins… ¿No te lo crees? ¿Conoces a el Gwapo?

 

¿Realmente me afecta?

Claro, la situación actual en estas PYMEs es pensar “a mí no me va a pasar”. Es un razonamiento habitual que se convierte en pánico cuando algo ocurre.

Pero volviendo a lo que te contaba, si te encuentras en esta situación en la que la empresa no tiene intención (por economía o decisión) de invertir en seguridad, al menos ten en cuenta estos cinco consejos que te ayudarán (sin apenas gastar un euro) a evitar, al menos, los ataques de botón gordo (aquellos que pueden realizarse sin conocimientos técnicos avanzados).

 

1) Examina tu información pública y semi pública:

La primera fase de un ataque sobre tu empresa va a consistir en la búsqueda de información que pueda aportar un mapa de lo que hay tras tu “fachada”.

Tener conocimiento de lo que enseñas es básico para intentar controlarlo y tratar de no ofrecer más de la cuenta. Para hacerlo, puedes usar algunos servicios web que te van a ofrecer una visión de cómo se te ve desde el exterior, como por ejemplo:

IntoDNS.com: te ofrece un informe de los que tu DNS dice de ti

intodns

DNSQueries.com: te ofrece varias utilidades para conocer información sobre tus sistemas de cara al público (dominio, ips, banners, puertos abiertos…).

dnsqueries

BriConsejo: trata de no mostrar banners, logs o servicios que no sean necesarios para tu actividad. Toda la información que no esté estrictamente relacionada con tu negocio, no debe estar expuesta.

 

2) Monitoriza tus servicios y servidores:

En muchas de estas empresas hay problemas incluso para saber si las cosas funcionan o no. Tener un control sobre si tu negocio está operativo es esencial y puedes contar con herramientas sencillas y gratuitas para conseguirlo.

Nagios / Icinga: dos sabores (el segundo es un fork del primero) para monitorizar de forma interna tus procesos y recursos, con ellos puedes tener todo bajo control

nagios

Monitor.us: servicio de la gente de TeamViewer que monitoriza de forma externa tus servidores, web… y te permite configurar alertas por mail y sms.

monitor

BriConsejo: saber qué o cuándo falla tu entorno es vital para poder recuperarse. En función de la actividad de tu negocio el tiempo que puedes permitirte tener algo parado es muy variable y puede ser vital.

 

3) Realiza una evaluación de seguridad de tus servicios:

Una auditoría de tus sistemas abiertos al público es vital, si tu empresa no quiere o no puede hacerlo con un profesional, al menos puedes utilizar ciertos servicios que te examinan e informan de las vulnerabilidades habituales.

WebSiteSecurityAudit: examina tu web o servidor en busca de vulnerabilidades y te las muestra ordenadas por prioridad junto con una explicación y consejos para solucionar el problema.

websitesecurityaudit

Detectify: similar pero con la posibilidad de recibir avisos y de exportar informes.

detectify

BriConsejo: trata al menos de eliminar las vulnerabilidades graves que te muestran estos servicios. Si ellos las detectan, alguien con mala intención también lo hará.

 

4) Haz copias de seguridad de tus datos importantes:

El espacio en disco está hoy en día casi regalado, no escatimes en backups y si son automáticos mejor (que al final siempre se nos olvida). Una solución híbrida que mantenga copias en local y remoto (puedes usar un disco duro y algún servicio cloud) te permitirá tener todo a buen recaudo por muy poco dinero.

Cloudberry backup: vale, no es gratis pero son apenas 30€ que te permitirán automatizar tus backups cifrando todo con unos sencillos clicks.

cloudberry

BriConsejo: ni lo pienses, tener tu información a salvo en varios lugares te costará muy poco y será maravilloso haberlo hecho si algún día lo pierdes todo…

 

5) Formación y concienciación del personal:

Habla con tus compañeros, envíales posts o noticias con incidentes de seguridad, puedes incluso utilizar el kit de concienciación de INCIBE o ponerles algunas de las charlas que te ofrecemos desde esta web.

Piensa que si consigues un pequeño cambio en la mentalidad de la gente, si consigues implantar una mínima cultura de seguridad en una PYME sin dinero habrás tenido éxito.

BriConsejo: al menos, trata de trasladar la necesidad del uso de contraseñas fuertes y de no abrir adjuntos de origen desconocido. Sólo con esto estarás haciendo mucho por tus compañeros.

 

Un vistazo general

Ojo, no estoy recomendando estos servicios como alternativas a un trabajo profesional, simplemente aconsejo este tipo de pasos en la situación particular de que te encuentres en una PYME sin dinero (para invertir en seguridad).

Quizás, poner en práctica estos consejos te pueda ayudar a cambiar la mentalidad de los que te rodean. Puede que poner sobre la mesa un pequeño informe con los problemas y soluciones detectados con estos cinco pasos sea el empujón necesario para que se comprenda que la seguridad no es un gasto si no una inversión que termina siendo rentable.

Como siempre digo, si ves algún error, no estás de acuerdo con lo que cuento o quieres hacer alguna aportación, no dudes en pasarte por los comentarios.

salt_pepper

Aliñando contraseñas en base de datos, ¿desarrollas o enriqueces?

En el anterior post hablamos de contraseñas desde el punto de vista de un usuario, de la importancia que tiene tener una buena política para evitar que sean sencillas de descubrir tanto a nivel de imaginación como de procesamiento mediante fuerza bruta.

En esta entrada vamos a centrarnos en las formas que hay para tratarlas y almacenarlas poniéndonos en la piel del desarrollador de aplicaciones.

La prehistoria… ¿o no?

Hace años, las aplicaciones que necesitaban gestión de usuarios se creaban implementando acceso a una base de datos en la que se guardaba la habitual pareja “usuario – contraseña”. Cuando se realizaba el proceso de login en el que el usuario indicaba sus credenciales (<user, <password>), bastaba con preguntar algo del tipo:

select user from users where user = <user> and password = <password>

Si obteníamos respuesta, entonces el usuario era quien decía ser, así de sencillo.

Esto, que debería ser algo totalmente obsoleto, todavía lo podemos encontrar en muchas más aplicaciones webs y de escritorio de las que creeríamos…

A modo de ejemplo, el dump de una base de datos MySql de una conocida marca de… (la llamaremos “Acuario” para no dar su verdadero nombre) almacena las credenciales de sus usuarios en un sistema vulnerable a ataques SQL Injection tal que así:

mysql_dump

Dump MySQL con información privada en texto plano

No hace falta decir que almacenar nombre, apellidos, usuario y contraseña de esta forma no es lo correcto, el desarrollador no ha hecho bien los deberes.

Almacenamiento de hashes

El siguiente paso fue dejar de almacenar los dos valores para almacenar el usuario y “algo” relacionado con la contraseña. Ese algo es un hash.

Un hash es el equivalente a una huella digital. Se consigue realizando un proceso matemático que da un valor de salida determinado a un objeto de entrada (podemos hablar de un fichero, un texto, un número…). Es importante tener en cuenta que un proceso de hashing debe ser irreversible, lo que quiere decir que no debemos ser capaces de calcular el objeto de entrada a partir del objeto de salida (ahí reside su fuerza como algoritmo).

Aunque no vamos a entrar en ellos, los algoritmos de hashing habituales son SHA (Secure Hash Algorith) y MD5 (Message-Digest Algorithm 5).

El sentido de todo esto es almacenar hashes en lugar de contraseñas. Así, si alguien ve nuestro hash, no le servirá de nada ya que no podrá deshacerlo.

En este caso, se ha dado un paso más para complicarle la vida a un atacante. Suponiendo que ha conseguido el dump de nuestra base de datos de usuarios, ya no lo tendrá tan sencillo como antes (recordemos que solamente tenía que saber leer para conseguir las credenciales). Ahora tendrá que realizar un ataque de fuerza bruta para generar hashes e ir comparando hasta dar con el objeto de entrada que genera el hash de salida almacenado en la tabla.

Aquí enlazamos con la importancia de tener una buena política de contraseñas, ya que existe lo que se conoce como “tablas rainbow” que son tablas con hashes ya calculados para grandes cantidades de posibles contraseñas.

Cuanto más sencilla sea nuestra contraseña, más probabilidad habrá de que se encuentre en una de estas tablas y que el atacante consiga las credenciales.

El funcionamiento desde el punto de vista del desarrollo es sencillo, cuando ingresemos nuestras credenciales <user> y <password>, se calcula el hash de la contraseña introducida y se compara con el que hay en base de datos, algo como:

select user from users where user = <user> and hash = hash(<password>)

En este ejemplo podemos ver una base de datos de prueba en la que se han obtenido los nombres de usuario y los hashes. Mediante un ataque de fuerza bruta con diccionario incluso se han podido sacar algunas contraseñas en claro.

hash_mysql

Dump MySQL con información privada hasheada y algunos valores obtenidos mediante fuerza bruta.

La práctica actual, “aliñando” el problema

Para atajar el problema de las tablas rainbow se ha optado por dar un paso más en complicar la vida al atacante. Surgen entonces los planteamientos con «salt & pepper» (sal y pimienta), que consisten en utilizar cadenas que se concatenan con la contraseña de usuario para convertir cualquier password débil en una password fuerte.

Imaginemos que tu contraseña es algo como “123456” (sólo números y longitud 6). El hash de esta contraseña va a estar en tablas rainbow, por lo que el atacante conseguiría credenciales casi al instante.

La aplicación podría añadirle el salt “f0Et%%kS*yJ@” y convertir tu pass en “123456_f0Et%%kS*yJ@”. Con este sencillo paso, tu clave débil se ha convertido en una clave fuerte, hemos conseguido una buena defensa frente a ese atacante.

Normalmente ese salt se almacena en la propia base de datos y se utiliza para realizar la consulta, que sería del tipo:

select user from users where user = <user> and hash = hash(<password>+salt)

Como alternativa o paso más, podríamos utilizar el pepper que es igual que salt, pero almacenado fuera de la base de datos.

hash_salt

Dump MySQL con hash y salt almacenados en la misma tabla

¿ Con esto ya estamos seguros?

La seguridad absoluta es una quimera, en nuestro caso (recordad que tenemos puesto el casco de desarrollador ahora mismo) nuestra intención es que los datos que almacenamos sean lo más complejos de obtener en el caso hipotético de que un usuario malicioso haya llegado a ellos.

Debemos poner medidas externas para evitar que se pueda acceder a la base de datos, pero tomar este tipo de controles es una buena práctica que todo desarrollador debe tener en cuenta.

Pensad siempre que si alguien quiere entrar, es posible que lo consiga. Cuantas más piedras le pongamos en el camino, más probabilidad tendremos de aburrirle en su tarea y de que decida cambiar por otro objetivo más sencillo.

Pero sobre todo, a nivel de imagen, no podemos permitirnos que los datos personales de nuestros clientes sean publicados, es nuestro deber aplicar medidas preventivas como estas, sobre todo cuando son tan sencillas de implementar.

 

Espero haberte ayudado con esta visión de seguridad en contraseñas desde los perfiles de usuario y desarrollador. En cualquier caso, si ves algún error, no estás de acuerdo con lo que cuento o quieres hacer alguna aportación, no dudes en pasarte por los comentarios.

¡Feliz semana!