cybercamp-visitante

Cybercamp 2015 – Mi experiencia como visitante

Hace unas semanas se celebró la segunda edición de Cybercamp, un congreso de seguridad organizado por INCIBE en el que se ofrecen charlas, talleres y otras actividades para profesionales y familias con un objetivo común: concienciar sobre la importancia de la seguridad de la información.

Los editores de SecurityInside no podíamos faltar, por la proximidad del evento (en mi caso personal) y porque varios de los nuestros son parte de INCIBE. Es por eso que os ofreceremos tres posts desde tres puntos de vista diferente: como visitante (este es el primero de ellos), como participante (nuestro compañero Pedro estuvo trabajando sin descanso en el hackatón) y como staff (el compañero Antonio formó parte de la plantilla que ayudó a que todo saliera redondo).

En este caso me toca contaros lo que vi en esas tres intensas jornadas de aprendizaje y diversión…

 

Día 1: Llegando a Cybercamp

Tras llegar y pasar por los controles y el mostrador de acreditación, pude comenzar a estudiar el plano. Debo decir que la localización de este año me ha parecido más confusa que la de la primera edición. Tuve algún que otro problema para poder acceder a las zonas, pero poco a poco me pude ir haciendo con el entorno.

 

The need of multi-tasking teams within cybersecurity departments

Aurélie Pols nos contó su experiencia profesional y personal en la que ve cómo la seguridad abarca cada vez más factores y ámbitos. La necesidad de estar al día de legislaciones (nacionales e internacionales), tecnología y cyberseguridad es ya algo que no se puede obviar y que nos exige más preparación a los profesionales del sector.

Puedes descargar la presentación aquí.

 

¿Cómo conseguir financiación para fundar mi startup de seguridad?

Javier Martín nos contó los secretos de la financiación y la forma en la que constituir tu empresa si eres, como yo, de los que quieren dar ese paso en un futuro.

Puedes descargar la presentación aquí.

 

Día 2: Mejora tu seguridad con herramientas Microsoft gratis

Simón Roses presentó un taller en el que habló de las herramientas que Microsoft pone a nuestra disposición de forma gratuíta y que pueden ayudarnos en la complicada tarea de la gestión de seguridad.

Puedes ver el vídeo del taller aquí.

 

How can (bad guys or even u) can rule the world?

Pablo González contó de primera mano la investigación que ha realizado en este año sobre la posibilidad de obtener una botnet con relativa facilidad, haciendo uso de información pública y servidores vulnerables.

Puedes descargar la presentación aquí.

 

Seguridad web: Ataques a la lógica de negocio

Miguel Ángel Hernandez dió un repaso a los problemas habituales en tecnologías web y cómo afectan a la lógica de negocio. Hizo una demostración en la que podía comprar tallas no disponibles o comprar en modo 2×1 basándose en errores no controlados de diferentes webs.

Puedes descargar la presentación aquí.

 

Low-Hanging Fruit

Chema Alonso hizo una de sus presentaciones cargadas de humor en las que nos alertó de los peligros de centrarse en tecnologías de seguridad, dejando de lado lo básico como una buena política de actualizaciones, de contraseñas o de metadatos.

Puedes ver la presentación aquí.

 

21 días

Rubén Santamarta subió al escenario para dar una charla diferente. Nada de demostraciones técnicas y mucho de experiencia personal, algo que también ayuda a los que tenemos en mente salir del país y vivir alguna que otra aventura.

Puedes ver la presentación aquí.

 

¿Cómo se hizo «El bueno, el feo y el malo”?

Raúl Siles puso atención sobre los dispositivos móviles y los peligros que les acechan. Estamos conectados y no somos conscientes de lo sencillo que es tomar el control de determinada información.

Puedes descargar la presentación aquí.

 

HoneyStation, Detección, Análisis y visualización de Ciberataques en tiempo real

Francisco J. Rodríguez nos dejó a todos impresionados con una prueba de concepto de increíble calidad. Un trabajo personal que pone sobre la mesa información en tiempo real de los ataques que se están produciendo con todo tipo de detalle.

Puedes descargar la presentación aquí.

 

¿Qué hace un técnico de ciberseguridad en una empresa?

Gonzalo Sánchez realizó una presentación en la que nos contó los elementos básicos de un SGSI y la forma en la que aplicar la ISO 27.001 en un entorno corporativo.

Puedes descargar la presentación aquí.

 

Día 3: Python, hacking y sec-tools

Daniel García nos puso las pilas por la mañana temprano con un taller de Python orientado al desarrollo de herramientas de ayuda en auditoría.

Puedes ver el vídeo del taller aquí.

 

Cookies y privacidad

Alejandro Ramos nos contó lo descubierto en su investigación sobre el uso de cookies y la relación entre su uso y la privacidad de usuarios.

Puedes ver el vídeo del taller aquí.

 

Necesitamos OPSEC

David Barroso nos mostró cantidad de ejemplos reales en los que se hace necesaria una operativa de seguridad, tanto en entornos corporativos como a nivel de familia.

Puedes ver la presentación aquí.

 

Riesgos de seguridad en el siglo XXI: familias y profesionales

Román Ramírez nos dió un golpe de realidad poniendo sobre la mesa la exposición que tenemos, en un mundo interconectado, sobre nuestros datos personales. Quizá la charla más dura para un público familiar, pero llena de ejemplos totalmente necesarios.

Puedes ver la presentación aquí.

 

Mis conclusiones…

Estas son las charlas y talleres a los que pude asistir, pero quedaron muchas opciones en el tintero debido al solapamiento. Por suerte, todo el material está disponible tanto en la web de Cybercamp (sección de materiales) como en su canal de YouTube.

Además de todo esto, pude darme una vuelta por los stands de patrocinadores, los de ayuda a emprendimiento o a búsqueda de empleo, el hackatón, los retos de seguridad, las actividades para familias, los talleres de robótica… mil cosas que hacer y que aprender en tres días intensos pero divertidos.

Además, con el extra añadido de encontrar por allí a grandes amigos y conocidos. Detalles y discusiones aparte, un evento interesante en conjunto que aporta mucho a la concienciación, a la formación y al empleo.

El año que viene, más. ¡Allí nos veremos!

auditoria-de-codigo

Auditoría de código: algo necesario pero que nunca hacemos (parte 2)

En la entrada anterior de esta serie de posts dedicados a la auditoría de código, hicimos una introducción sobre los problemas derivados del trabajo habitual. Es muy normal que haya fallos, descuidos o simple desconocimiento en cualquier proceso en el que un humano participa.

Vimos que el desarrollo de software no es una excepción y pudimos comprobar cómo han ido evolucionando los proyectos para convertirse en auténticos mastodontes.

Llegamos a la conclusión de que auditar el código de grandes proyectos es algo necesario y establecimos un momento óptimo cercano al 70% de desarrollo sobre una rama estable y que pueda compilar. ¿Hasta aquí todo bien? ¿Seguimos?

Primer acercamiento al código fuente

Si el código no es nuestro (lo que es común en una auditoría) necesitamos saber a qué nos enfrentamos. No tardaremos lo mismo ni nos encontraremos con los mismos problemas en un proyecto con miles de líneas pero sencillo, que en otro con pocas pero excesivamente complejo.

Por lo tanto, nuestra primera misión es conocer elementos tales como:

  • ¿Cuántas LOC (líneas de código) tiene?
  • ¿Cuántas funciones? ¿Son sencillas o complejas?
  • ¿Utiliza APIs de terceros?
  • ¿Está bien comentado?
  • ¿Existe documentación? ¿Está actualizada?

No podemos olvidarnos de requisitos externos que pueden complicar el proceso. Hace unos años participé en proyecto militar en el que recibí un código fuente con las siguientes características:

  • El código fuente era de la versión 7.
  • La documentación era de la versión 4 (a partir de ahí desarrollaron con prisa y no hubo tiempo para actualizar… ¿os suena?).
  • Para compilar era necesaria una llave USB… que no tenía y que tardó varios meses en llegar.

Desde luego no es el mejor escenario. Cuando te enfrentas a un proyecto así, cuanta más información puedas obtener, más sencillo será tu trabajo.

Mi consejo cuando te enfrentes a un proceso de auditoría de código es: insiste, profundiza y no tengas miedo a ser pesado. Puede que preguntando tres veces en lugar de una obtengas datos que te sean de mucha ayuda.

Herramientas de información

En nuestro acercamiento al código fuente, nos será de mucha ayuda tener una visión de conjunto antes de entrar a saco con el código. Por suerte dispones de gran cantidad de herramientas que te pueden ayudar en este paso.

En la siguiente captura podéis ver un ejemplo de una de esas herramientas (en este caso Code Analyzer) evaluando un pequeño proyecto java.

Análisis de proyecto con Code Analyzer

Como podéis ver, de forma rápida nos ofrece una visión de conjunto indicando LOC, comentarios, espacios en blanco

Complejidad del código

El siguiente paso será evaluar la complejidad funcional de lo que tenemos entre manos. Esto será una tarea sencilla si recibimos una buena documentación en la que todos los procesos estén descritos a nivel funcional (si hay diagramas de secuencia entonces será todo un éxito).

Si no lo tenemos, tendremos que evaluar el código realizando una tarea inicial de análisis de caminos independientes que se pueden tomar en los if-else, switches, cases, bucles… para trazar un mapa y poder contarlos.

¡Ojo! No te confundas, no se trata de contar sin más, debes evaluar las opciones. Mejor vemos un ejemplo, ¿no?

En este caso podemos ver claramente que la existencia de dos condicionales hace que existan tres caminos diferentes de ejecución:

  • Camino A: La variable es menor que 10.
  • Camino B: La variable se encuentra entre 10 y 20.
  • Camino C: La variable es mayor que 20.

Esto se puede hacer a mano, pero también dispones de herramientas que te ayudarán a hacerlo de forma más sencilla, aquí tienes algunas de ellas:

En esta captura puedes ver el resultado de consultar la complejidad utilizando el plugin Metrics para Eclipse sobre el proyecto JAVA anterior:

Complejidad ciclomática con Metrics para Eclipse

El resultado lo podremos interpretar de la siguiente forma:

 Medidad de complejidad

Significado

1-10

  • Código estructurado con facilidad para hacer pruebas.
  • Poco riesgo de seguridad asociado.
  • Coste de auditoría bajo.

10-20

  • Código complejo con dificultad media para pruebas.
  • Riesgo medio de seguridad.
  • Coste de auditoría medio.

20-40

  • Código muy complejo con gran dificultad para pruebas.
  • Riesgo alto de seguridad.
  • Coste de auditoría elevado.

>40

  • Código excesivamente complejo, es muy probable que no se puedan realizar todas las pruebas.
  • Riesgo muy alto de seguridad.
  • Coste de auditoría muy elevado.

NOTA: Si quieres profundizar más sobre el cálculo de la complejidad ciclomática, estos enlaces te serán de gran utilidad:

Planificando la auditoría

Una vez tenemos el código y hemos comprendido a qué nos enfrentamos (LOC, complejidad, documentación…) estamos en condiciones de afrontar el proceso y qué mejor forma que haciendo eso que tanto nos gusta, planificar.

Lo principal será definir el equipo que se va a encargar de realizar la auditoría, puede ser una persona o muchas más (como siempre, dependerá del presupuesto, la urgencia y varios elementos específicos del proyecto).

La recomendación es que se trate de varias personas con formación y experiencia en ámbitos diferentes. Sería ideal contar con alguien especializado en diferentes entornos de desarrollo (escritorio, móvil, web), lenguajes o sistemas.

Planificaremos entonces una serie de sesiones semanales en las que cada miembro del equipo tendrá plena libertad para usar aquellas herramientas o técnicas con las que se sienta más cómodo (de ahí la importancia de que el equipo tenga diferentes perfiles).

Cada día se realizará una reunión de seguimiento corta (siguiendo la idea de SCRUM) y después se iniciará el proceso por el que cada miembro se encargará de un máximo de 1000 LOC/h y durante un máximo de 3 horas, ya que la concentración es muy importante en este proceso y no conviene que el equipo esté cansado o aburrido (lo cual es fácil cuando llevas un par de horas leyendo código de otro…).

¿Qué nos queda?

Tenemos y conocemos el código, longitud, complejidad, documentación y requisitos de funcionamiento. Tenemos al equipo listo con una cantidad de horas y LOC asignadas. ¿Tenemos ganas de empezar?

Pues nos vemos en la siguiente entrada en la que profundizaremos en las fases de la auditoría, en las tareas habituales y en un montón de cosas más.

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.

auditoria-de-codigo

Auditoría de código: algo necesario pero que nunca hacemos (parte 1)

A lo largo de varias publicaciones, vamos a adentrarnos en el mundo de la auditoría de código para ver lo importante que es tener cierto control de lo que se hace para poder construir nuestro software de la forma más segura posible.

Una pequeña (bueno, no tanto) introducción

En el mundo de la seguridad de la información, como en todo, hay ciertos elementos más importantes que otros y que impactan de lleno sobre la posibilidad o no de que algo ocurra.

El usuario es un actor principal dentro de este mundo. Lo que yo llamo la “constante de inutilidad” (capacidad para cometer errores con los que decir “joer, qué inútil soy!”) de las personas es un factor vital para la seguridad global de un sistema, ya que si ponemos cientos de medidas pero el usuario publica la contraseña maestra en Facebook, estamos perdidos…

Todos tenemos un torpe en nuestro interior que nos empuja a cometer fallos, a despistarnos, a relajarnos y a dejar pasar cosas de forma inconsciente y (más a menudo de lo esperado) totalmente consciente.

Esto mismo se puede llevar al mundo del desarrollo de software. Cada vez que nos ponemos el mono de desarrolladores y comenzamos a picar código, podemos cometer una serie de errores o seguir patrones “desaconsejables” que pueden hacer que nuestro resultado sea totalmente vulnerable.

La evolución del código fuente

A lo largo de las últimas décadas, el desarrollo de software ha crecido exponencialmente. El uso de nuevas tecnologías en un mundo cada vez más conectado ha creado una gran dependencia de software que gestione y coordine todo.

Cuando comencé en esto de la informática, me dedicaba a escribir en BASIC programas de decenas de líneas, incluso me atrevía a hacer cosas con cientos de líneas que luego grababa en cinta.

Hoy en día, cualquier desarrollo sencillo se nos va a los miles y crece de forma increíble si hablamos de grandes funcionalidades. Mira, por ejemplo, cómo van creciendo las cifras conforme hablamos de software (loc = lines of code):

100.000 loc

Photoshop 1.0

2.500.000 loc

Windows 3.1

9.500.000 loc

Firefox 38

40.000.000 loc

Windows 7

61.000.000 loc

Facebook

 

¿Y esto en qué nos afecta?

Lógicamente, cuanto mayor es algo que hacemos, más probabilidad de fallo hay en su interior. Este tipo de soluciones software se desarrollan por grandes equipos de personas que cuentan con peculiaridades, manías y constantes de inutilidad diferentes.

En este escenario aparecen siempre fallos, problemas, descuidos que harán que ese software sea vulnerable, poniendo en peligro a la organización, empresa o usuario que lo utiliza.

Ahorra mientras solucionas

Generalmente se suele ver “desde arriba” que los procesos de auditoría de código son una pérdida de tiempo y que si surge un fallo, ya se arreglará. La verdad es más cruda, arreglar fallos se vuelve más y más caro cuanto más avanza el desarrollo.

Solucionar, mitigar o eliminar posibilidades de fallo es sencillo y barato en el momento del diseño. Hacerlo cuando hay varios millones de líneas y cientos de usuarios haciendo uso del software se puede volver inmensamente complejo y costoso.

Entonces la pregunta que surge es directa, ¿cuándo se debe hacer una auditoría de código? El momento óptimo ocurre cuando estamos alrededor del 70% del desarrollo de cada versión funcional y sobre un proyecto que podamos compilar.

¡Pero mucho ojo!, hay que buscar equilibrio entre el desarrollo y el auditor, el objetivo es mejorar, no entorpecer.

¿Manos a la obra?

En esta entrada sólo queríamos hacer una introducción al proceso de auditoría de código para ir avanzando en las siguientes entradas. Si te parece interesante lo que hemos empezado a contar, no dudes en pasarte por aquí para entrar en detalle.

¡Te esperamos!

sandbox-caja-magica

Sandbox «La Caja Mágica»

¿Que es SandBox?

Sandbox viene del anglicismo «caja de arena» que se utiliza mucho en países americanos para que los niños jueguen sobre todo en época de verano, en el término de seguridad un SandBox es una máquina virtual donde se corren los procesos maliciosos antes de que lleguen al usuario final.

En la actualidad existen en el mercado varias soluciones de SandBoxing que nos dan un gran abanico de opciones y de sabores.

¿Porqué implementar un SandBox en mi organización?

Es una de las preguntas más complejas de responder pero más fáciles de explicar.

Recientemente se ha venido incrementando los códigos maliciosos específicamente el «malware» que busca sacar dinero a los usuarios de la organización ejecutando programas de procedencia «no confiable», un ejemplo palpable lo tenemos recientemente con el Cryptolocker que cifraba los datos del afectado y pedía un rescate para enviarte la llave para descifrar los datos.

Si tenemos un solución de SandBoxing permitirá que antes de que le demos clic a una imagen, url, fichero o cualquier tipo de información adjunta al correo electronico se ejecute en una máquina virtual comprueba si es de fuente confiable y que no venga codificado (código malicioso), luego de verificar que el correo electronico es confiable o legítimo le permite al usuario abrir el contenido anexado sin ningún tipo de riesgo a infecciones o robo de información.

¿Cuanto tiempo me lleva implementar una solución de SandBoxing?

Dependiendo de la casa fabricante que elijamos podremos tener un tiempo de implementación corto y que se reduce en complejidad del proyecto y dedicación de recursos.

Existen soluciones que se integrarán nativamente con las demás soluciones que tenemos en nuestro entorno corporativo como por ejemplo las consolas antivirus o los servidores de parcheo de sistemas corporativos, teniendo como especial punto que en estos últimos sistemas se aloja el core business es decir, los sistemas que mantienen el negocio y que deben de funcionar las 24 horas los 365 días del año con un porcentaje superior al 99.9999% de disponibilidad.

En este sentido lo más lógico sino queremos tener recursos dedicados al proyecto o evitarnos la complejidad de una implementación podemos contratar servicios en la nube (cloud) que hoy en día ofrecen la mayoría de los fabricantes.

¿Cuanto cuesta una solución de SandBoxing?

No te cuestiones ni de vueltas a la hora de invertir en este tipo de soluciones, la respuesta seria la siguiente: «¿Cuánto dinero pierdes si un código malicioso te bloquea o roba la información?»

Muchas veces lo primero que nos preguntamos es cuanto cuesta pero nunca hemos realizado un ejercicio de riesgo tecnologico o una matriz de riesgo que nos plantee en dinero $$$$ €€€€ cuánto perdemos hora/hombre hora/negocio si tenemos por ejemplo «Cryptolocker acechandonos», cuando una verdad es cierta cada dia las mafias mejoran mas y mas el codigo haciendo que sea una lucha de hormiguitas o que la labor de bloqueo de URL en los Firewalls sea prácticamente imposible.

¿Quién nos puede asesorar en este tipo de soluciones?

Más que vendernos una solución lo clave es buscar la persona o la consultora que nos de no solo una consultoría experta porque instalar «facil» pero tunear una solución de SandBoxing es donde está el secreto.

Por eso es preferible si no somos expertos contratar horas de servicio del propio fabricante que nos sirva para llevar a cabo el proyecto sin ningún tipo de contratiempos.

Finalmente les dejo algunos URL que les servirán para ampliar esta información.

Hasta la próxima……

https://blogs.mcafee.com/business/security-connected/thinking-outside-of-the-sandbox-mcafee-advanced-threat-defense-unveiled

https://blogs.mcafee.com/business/developing-the-ultimate-defense-against-advanced-malware

http://blog.trendmicro.com/trendlabs-security-intelligence/deploying-a-smart-sandbox-for-unknown-threats-and-zero-day-attacks/

https://support.symantec.com/en_US/defaultProductLanding.63070.html

http://docs-legacy.fortinet.com/fos50hlp/50/index.html#page/FortiOS%205.0%20Help/antivirus_chapter.150.25.html

 

 

 

 

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!