Hola amigos, bienvenidos a esta clase, donde vamos a hablar sobre otra de las vulnerabilidades de
WhatsApp, en este caso vamos a hablar de la pérdida de autenticación que hecho se nos mostrar en pantalla.
Fíjense que este era uno de los primeros archivos que estábamos viendo.
Fíjense Z Mega, acá va un poco de explicaciones, pero me interesa sobre todo darles mi punto de vista
y explicárselos con mis palabras.
Efectivamente, cuando hablamos de pérdida de autenticación es bastante interesante esta segunda vulnerabilidad
y es sobretodo interesante entender que justamente es la top 2 de algo que definitivamente si no lo
hemos visto hasta ahora en este curso más largo que definitivamente vamos a ver y es justamente la del
analfabetismo tecnológico.
El analfabetismo es una informática, el desconocimiento de la debilidad al momento de ele crear una
contraseña en momento de querer iniciar sesión dentro de la galaxia y la cantidad de variables que existen
hoy en dia en donde un atacante puede llegar a vulnerar nuestro.
Inicie sesión desde el principio de que porque ustedes fijaron la contraseña guardada en su computadora
porque lo deja, la dejaron escrita en un papelito y lo pegaron al lado del monitor en su trabajo porque
utilizaban contraseñas débiles.
Por eso es importante este punto y me parece importante también desarrollar bastante en relación al
tema independiente, a la parte práctica, que va a estar también bastante interesante, sino por decir
graciasa.
Pero es importante que entiendan que pueden existir debilidades de autenticación, si es que justamente
en este caso vamos a hablar de la perspectiva de la aplicación, por ejemplo, por ejemplo, para permitir
ataques automatizados como la reutilización de credenciales conocidas.
Con esto a lo que hago alusión es la típica que se conoce por a por el mayor uso que tiene que WordPress.
WordPress es un CMS que te permite crear páginas web sin citar para saber programar y justamente los
WordPress tienen determinadas configuraciones genéricas en donde si uno no las revisa no las toca.
Justamente lo que termina sucediendo es que vamos a sufrir un ataque porque el WordPress hoy en día
al tener este factor genérico, lo ciberdelincuentes tienen automatizada los ataques, o sea, van escaneando
internet hasta que encuentran un WordPress.
Dicen bueno, acá este es un WordPress.
Intentamos lo de Peyo medio loggia en punto PHP entró, no lo cambió a la hoja.
Bueno, entonces entró.
Entramos ataques de fuerza bruta.
Con el primero podemos escanear a ver si podemos ver los usuarios.
Empieza todo un procedimiento automatizado.
Ni siquiera implica la inversión de tiempo físico por parte del ciberdelincuentes para llevar adelante
ese ataque.
Justamente esto es lo que yo me refería al anteceder ataques de fuerza bruta y obviamente el hecho de
utilizar contraseñas débiles por defecto o muy conocidas, que justamente es lo que permite esto es
que uno sea más vulnerable ante un posible ataque por diccionario.
Recuerda que diccionario es un listado de contraseñas conocidas o de frecuente uso o filtradas ante
determinado hackeos conocidos, donde ya hemos visto también las páginas web, en donde justamente se
encuentra una base de datos, en donde está almacenado las diferentes contraseñas que se han filtrado,
o sea que han robado ciberdelincuentes de redes sociales, páginas web conocidas y que justamente gracias
a esto es que hoy en día pueden armagnac cionarios.
Y si nosotros no tenemos esa contraseña o evitamos esas contraseñas, vamos a poder ser susceptibles
a ese tipo de ataque.
Luego también voy a analizar si existen procesos débiles en el proceso de la recuperación de contraseñas.
Este punto es bastante interesante porque independiente también al hecho de cuando uno va a recuperar
la contraseña, implementar seguridad en ese aspecto, sino también en el mensaje que nos devuelve el
iniciar sesión en la aplicación.
Porque si nosotros ingresamos usuario contraseña y la aplicación ya nos dice que la contraseña es la
que está equivocada o viceversa, sabemos que entonces el otro es correcto.
A qué me refiero?
Si yo pruebo un usuario X y me quedo con la contraseña me dice la contraseña es equivocada.
Entonces yo ya descarto que el usuario es correcto.
Incluso tengo un factor menos que.
Adivinar, por ejemplo, también es importante tener en cuenta el almacenaje de las contraseñas.
O sea que me refiero justamente que se en cifradas con mucha seguridad.
De esa manera, por ejemplo, esto que les comentaba de las páginas web conocidas en los de se han filtrado
contraseñas no sería un problema, porque justamente si estaban cifradas o con un alto nivel de seguridad
nunca se hubiesen dado a conocer.
También suelen no poseer auténticas autenticación multifactorial o no fue implementada de una forma
muy ineficaz.
Por ejemplo, o por ejemplo también.
Otro error en las páginas web es cuando se expone el Heidy de la sesión en la Urrelo, por ejemplo,
sea que se envía la información de manera errónea como algo muy parecido a lo que estaba ocurriendo
en la clase.
En la parte de inyección SQL y hablando como también en pantalla de autenticación y autorización.
Es interesante en este punto diferenciarlo, ya que la autorización es cuando existe una lista de permisos
para validar con un usuario y su perfil y la autenticación es cuando el sistema la valida de validar
un usuario por medio de sea algo que conoce, algo que es, por ejemplo, datos biométricos.
Todos estos pasos son importantes porque son como las capas de seguridad que podemos darle.
Como les dije, control biométrico y huella digital, pulso, corazón inclusive o algo que tiene como
un token o un Pendry, o un software o un hardware que permite la autenticación al momento de querer
ingresar al sistema, por ejemplo.
También es importante tratar de entender los mecanismos de autenticación e intentar varias veces odiarse
de todas las formas de las formas diferentes.
A ver qué pasa.
Acá ya estamos hablando de la perspectiva del atacante, por ejemplo, ver la verificación de la autocumplidas
del password o buscar contraseñas vacías o problemas con el metodo recuperación de Condorcet o dicho
el código fuente.
Esto es algo recalcada, importante el código del código fuente.
A ver si hay algún comentario, algo este.
Este error es típico.
Se veía mucho en GitHub que hija para quien no conoce es un repositorio en donde uno puede subir código
mucho programado exterminadas subiendo el código con la contraseña comentada.
Entonces la gente se descarga el código y de ahí a la contraseña comentada.
Por ejemplo, ver si hay políticas de claves con políticas de clave.
Me refiero a esto justamente de bueno mayúscula, minúscula, 12 caracteres, alfanumérico, numérico,
etcétera.
Y bueno, así podemos ir identificando varios problemas.
Luego también en otro punto a analizar en los formularios de login, ver que tan inseguro son de usar
un próximo un proxy para ver cómo es el proceso de autenticación del sistema, testear fallas de SQL
Injection como ya hemos visto.
Bueno, nosotros vamos a utilizar el broken outs en la máquina que tenemos.
Hay que probarse.
Uno se puede guiar, entender cómo el proceso de la autenticación por detrás y analizar el código fuente
para encontrar pistas en el caso que la podamos encontrar.
No, ni hablar del password con debilidad como les había mencionado.
Y también existen el factor del captcha, como muchos hoy conocerán cuál es la solución a esto.
Ya para ir finalizando esta clase y respondiendo a una de las típicas preguntas.
Una posible solución a esto es implementar una auténtica una autenticación multifactorial para evitar
ataques automatizados, por ejemplo, o limitar el intento de iniciar sesión.
Implementar en las cookies los parámetros secu siquiere y http only.
Por ejemplo, administración usuarios se conecta con más de una dirección de origen, o sea una IP.
Así como hace Simmel hoy en día que si alguien se intenta conectar en un dispositivo desconocido o una
IP distinta a la que nosotros solemos conectarnos, nos avisa, por ejemplo, no utilizar credenciales
por defecto en su aplicación, particularmente en el caso de los administradores, ya que si logran
entrar por los administradores van a tomar el control de todo e implementar controles contra contraseñas
débiles, por ejemplo, lamenten.
Solamente el ser humano es hijo del rigor.
Hay que forzar el tema, como hacen con los magos que te obligan a cambiar, a conducir una vez al mes.
Bueno, acá sucede lo mismo.
No hay que dejarle la decisión en las personas.
También alinea la política a la longitud, complejidad y rotación de contraseña, el límite o incremento
de tiempo en la respuesta en cada intento fallido de iniciar sesión.
El registro de todos los fallos tipo formato log que avisa a los administradores cuando extricta en
un ataque fuerza bruta, por ejemplo.
Y también se puede utilizar un gestor de sesión en el servidor integrado seguro y que genera un nuevo
Heidy de sesión aleatoria con alta entropía.
Por ejemplo, después del inicio, sesión y sesión hoy día, como lo había mencionado, que no debe
incluirse en la abrele, debe de almacenarse de forma segura y ser inválido después del cierre de sesión.
Eso es importante de un tiempo o de un tiempo de inactividad determinado de del usuario.
Estas son algunas de las medidas que se pueden tomar hasta la próxima clase.
Vamos a estar viendo la parte práctica, pero que le haya gustado la clase.
Les dejo un abrazo, digita.