Familia Digital.
Bienvenidos a este video.
Está Doña OnStar hablando de la vulnerabilidad número cinco dentro del top ten de Hoops Mobile.
En este caso vamos a hablar de la criptografía insegura, más insegura.
Perdón, además de insegura e insuficiente técnicamente así lo llama el top ten.
Justamente acá vamos a retomar pequeñas cosas que inclusive ya hemos dicho mencionado con anterioridad.
Y es que justamente no es casualidad.
Cuando yo les mencioné que todo tiene que ver con todo y hay una razón también por la cual yo les voy
mencionando determinadas cosas.
Por eso, teniendo en cuenta la criptografía insuficientes, estamos hablando de la problemática de
que la información viaje a través de los canales de la comunicación de una manera o en un formato que
no sea fácil de leer, si es que alguien lo intercepta a través de métodos como Manni, Hindemith,
a través de Bullshit o la herramienta que ustedes quieran.
Zapp también podría ser una alternativa.
Entonces vamos.
Les voy a compartir una realidad mi pantalla y como siempre, les muestro al gastÃ criptografía insuficiente
donde crecí.
Fíjense que acá también no lo dice muy relacionado con él .3 comunicación insegura.
Y es que definitivamente no me voy a cansar de decir que la seguridad informática todo tiene que ver
con todo.
En este caso, bueno, los datos viajan por un canal de red.
No, no están bien encriptado y son fácilmente descifrados.
Bueno, les voy a compartir mi ICAP, la diapositiva que preparé para esta clase y justamente el primer
ítem que hice.
La reutilización característica en desarrollo aquí es mala práctica.
A qué me refiero con esto en desarrollo?
Que de hecho yo lo veo como una bondad algo positivo.
Es muy característico.
Y hay una frase que dice que el 80, el 90 por ciento del desarrollo reutilización y un 20 un 10 por
ciento imaginación.
Esto hace alusión a que, por ejemplo, en los lenguajes que sea que ustedes estén desarrollando, muchas
veces a raíz de buscar errores o utilizar librerías, sin ir más lejos, paquete, etcétera.
Estamos reutilizando el código de otra persona y no tiene nada de malo porque no es necesario reinventar
la rueda.
Pero hay ciertas malas prácticas que inclusive esto lo vamos a seguir retomando en secciones futuras,
sobre todo cuando hablemos de Hoops Happy.
Pero yendo a la clase esta concreta un error que suelen caer o que por lo menos yo he visto mucho en
que tienen que ver con la criptografía insuficiente cuando hablamos de desarrollo de aplicaciones móviles.
Es que justamente los desarrolladores utilizan algoritmos cripto gráficos con vulnerabilidades ya publicadas.
O sea, yo me refiero justamente encuentran algún algoritmo a raíz de googlear o a o el método que sea,
pero no se fijan si ese algoritmo tiene alguna vulnerabilidad con vulnerabilidad.
Me refiero a que justamente es fácil de cifrar, o sea, de a pesar de que alguien lo capture, tenga
la capacidad de descifrar ese esa encriptación de esa criptografía y poder leer en él el mensaje o en
este caso el usuario la contraseña.
Por eso hago referencia KKK en a la reutilización de un algoritmo criptográfico que ella ya tiene vulnerables
y por ende heredan esas vulnerabilidades.
También es cierto y hay que tener en cuenta que algunos desarrolladores se lanzan para hacérselo a la
aventura, o sea, ellos mismos quieren desarrollar sus propios algoritmos cripto gráficos, donde acá
denota un claro riesgo, ya que subestiman el trabajo de lo que significa creer un algoritmo de crear
un algoritmo criptográfico, ya que por detrás hay un trabajo exhaustivo, sobre todo matemático, porque
eso hago alusión cuando hablamos de algoritmo criptográfico.
Hay algoritmos matemáticos que hacen que la información no se pueda leer.
Bueno, justamente el trabajo más exhaustivo que hay por detrás.
Y no, nada es casualidad.
Cuando se crea un un algoritmo criptográfico para solutamente e ir e ir superando los desafíos de pruebas
de seguridad informática y también el otro error que le pudo cometer que es muy común ver que.
Km que obviamente es la falla en la implementación o el mal manejo de las llaves que ortograficas para
que se vayan situando en donde?
En que parte de la diapositiva estoy hablando?
Ya hemos pasado, estamos en serie de utilizar criptografía fuerte, por ende deben de evitar saws 1
md5 o anteriores, inclusive acá pueden utilizar en la combinación de diferentes llave, por ejemplo
ya 556 con 512 por ejemplo ir en bebiendo por así decirlo.
Sabes escripto gráficas.
Luego ya yendo un poquito más al último punto del cuidado con las funciones que ortograficas simétricas,
es muy importante que justamente conozcan que existen y que de hecho e inclusive ya lo hemos mencionado
con anterioridad, cuando hablábamos de WhatsApp, de un ejemplo que yo les daba y que justamente hay
que tener mucho cuidado con las funciones gráficas simétricas.
Como les decía, el ejemplo de esto es whassap, la cual es la misma llave que sirve para cifrar la
información o por ende, como yo lo decía de manera gráfica, la misma llave que te abre la puerta es
la misma llave que cierra al salir el mensaje, y esa llave se encuentra en este caso dentro del celular.
Bueno, justamente pasando en limpio una a una función criptográfico simétrica es la que utiliza la
misma llave que se utiliza para cifrar en se utiliza para descifrar.
Por lo cual si obtienes esta llave vas a poder leer la información.
Ese es el problema y a raíz de diferentes métodos se puede llegar a tener esta información.
Por eso esta forma simétrica no es la más recomendable para almacenar la información de manera local.
Ya me sé en una base de datos SQL lait por ejemplo, característica dentro de Android, cosas que ya
le he mencionado con anterioridad.
Por eso se recomienda utilizar funciones cripto gráficas asimétricas con clave de longitud.
En este caso, vamos, vamos a desarrollar un poco a qué me refiero con claves de longitud y criptografía
asimétrica éti caso.
Cuando hablamos de una criptografía asimétrica son dos llaves distintas, una para cifrar y la otra
para descifrar.
La que lee esta última, o sea, la de descifrar en la privada.
Osea, esa llave no se debe de distribuir, se debe mantener de manera protegida y de forma inaccesible,
o sea, por parte de la aplicación que se bueno para justamente
cifrar la información.
En este caso desde la aplicación es la otra llave que es la llave pública.
La la que va a servir para cifrar la información es esa llave.
No es problema que justamente sea de fácil acceso, por así decirlo.
La seguridad en la metodología asimétrica en la criptografía asimétrica erradica esta metodología de
la seguridad en la criptografía asimétrica radica en la longitud de las llaves.
Y acá este es otro error muy común que suelen caer, ya que en la en la longitud de las llaves siempre
se recomienda utilizar por lo menos una longitud RSA por lo menos de cuatro mil noventa y seis.
Se lo voy a escribir en pantalla como para que sea un poco más claro.
Vamos, vamos a utilizar un output.
Yo lo que le estoy hablando ahora es justamente primero criptografía, criptografía asimétrica.
Bien, acá lo que yo le estoy diciendo es que existe una llave llave privada y pública.
La privada es para cifrar y dijimos que la pública es para de sí para bien.
Y qué pasa?
Una de las formas claves para poder brindarle seguridad a esta llave es el la longitud.
Como les explicaba donde estamos hablando entonces de la longitud de las llaves.
Acá yo les digo que justamente el algoritmo que el algoritmo se utiliza es el RSA y por lo menos 4000
96.
Cuando te ven estos números recuerden que siempre cuando por ejemplo hablábamos en las unidades.
Megabyte humeaba hay un siÂ para ser zelot.
Son 1024 mirabais height, entonces se iguala pues llega un llegaba a.
Siempre en este formato, en o 512 ven que es la mitad.
Si multiplicamos por 2 y acabo de ver también 2 56, son las medidas que nosotros siempre utilizamos.
Bueno, acá pasa lo mismo.
Si esto lo multiplicamos por 24 van a ver que les da 4 1096.
No, Cal.
Gracias.
Si hacemos 1024 por 4 millones de no es casualidad.
Qué pasa?
Por lo general el error en el que caen es que utilizan con longitudes baja 512 1024 caen en ese error
cuando eligen la longitud y lo cual es un error muy común.
Obviamente, fuera de todo esto que les estoy mencionando, en el peor error que pueden llegar a caer
es justamente mandar la información por texto plano, lo cual significa no cifrar la información ni
con asimétrica ni simétrica, ni ninguna otra metodología.
Eso es lo peor que puede llegar a suceder, por así decirlo.
Por eso Uds. siempre para brindarles un poco de experiencia y de práctica, por así decirlo, siempre
han de revisar el código de la aplicación para detectar qué tipo de cifrado están utilizando y si hay
llave simétrica o si está insertado en el código para ver la información en este caso.
Por eso, muchas veces también, inclusive se recomienda ofuscar el código de la aplicación, porque
por más que esté compilado en una Peka o en el formato que ustedes quieran, el.
El experto en seguridad informática sabe cómo acceder al código de la aplicación.
Si acceden al código de la aplicación van a poder ver a través de qué método están enviando y recién
a la información.
Y por eso es que tener cuidado con ese aspecto en cuestión.
Bueno amigos, espero que les haya gustado la clase.
Les dejo un abrazo digital.