[LACNIC/Seguridad] ¿Cuanto tiempo tarda un hacker en,descifrar una contraseña?

Mar Nov 15 18:49:25 BRST 2011

Buena explicación Carlos y de acuerdo con lo de los ataques de fuerza bruta
que en la práctica no van.

gracias

2011/11/15 Carlos Bergero <rak en fcien.edu.uy>

>  Es una buena pregunta, ¿Por cuanto tiempo tu contraseña sera segura?
> Yo diría que esto es dependiente del entorno en el que estás.
> Por ejemplo, un número de PIN de una tarjeta de cajero, es una contraseña,
> ok no es el mejor ejemplo práctico pero, es una contraseña.
> Otro ejemplo puede ser, mi clave de facebook.
> O mi clave de usuario en linux en el servidor xyz.
> Todas estas son claves/contraseñas, pero están en entornos muy distintos,
> así que analicemos un poco las cosas,
>
> Caso 1 PIN del cajero.
> Para poder atacar el PIN de mi cajero primero tiene que hacerse con mi
> tarjeta, esto abre un abanico de opciones.
>
> Copia de la tarjeta.
> * Sustracción por poco tiempo para hacer la copia, ie en el trabjo dejé la
> cartera/billetera por ahí y un oportunista la tomó y la copió.
> * Copia en un local comercial, este último caso aplica más que nada a las
> tarjetas de crédito o débito, y por en muchos casos el atacante tiene
> acceso físico a snoopear tu pin.
> + Si cualquiera de los dos ataques fue exitoso en copiar la Tarjeta pero
> no en ver el pin, lo que no siempre es posible, el plástico sin pin es más
> probable que se use para "falsificar" compras que para usarse en un cajero,
> pero si solo se pudiera usar en un cajero, es razonable pensar que el
> atacante utilizará claves frecuentes, ie 0000 1234 0123 3210 etc, en todo
> caso tiene 2 intentos y después está afuera o tiene un cooldown hasta que
> el sistema de cajeros se relaje y considere que no están atacando el pin. (
> esta en forma genérica es la mejor defensa contra ataques de este tipo)
>
> Robo de la tarjeta.
> * Si el robo de la tarjeta es evidente, es muy probable que los atacante,
> maleantes más que atacantes, también realicen un ataque a la integridad
> física del dueño de la tarjeta y lo obliguen a entregar la clave o vaciar
> el cajero por su propia cuenta. Con lo que la clave pasa a ser irrelevante.
> Perdida de la tarjeta.
> La perdida de tarjeta, sufre el mismo ataque que la copia en el caso de
> que no se puede snoopear el PIN.
>
> Con este simple análisis se puede considerar que lo más conveniente para
> el caso de PINs de tarjetas, es usar un n´umero sencillo pero no trivial de
> clave, la posibilidad de que el atacante utilice información del dueño de
> la tarjeta, como los últimos 4 o los primeros 4 números de la cédula, el
> pasaporte, el día de cumpleaños de 2 personas que conoce es posible pero
> genera suficiente complejidad como para que la protección del cajero o la
> Time out de denuncia de la tarjeta la hagan caducar como toquen válido.
>
> Con respecto a los otros dos casos comparten una serie de características
> comunes,:
> 1.- El toquen en cuestión se puede considerar en la mayoría de los casos
> público o semi público, ya que o bien aparece en direcciones de correo o es
> obtenible/deducible de fuentes existentes en internet, en la mayoría de los
> casos listas de mail o deducible de páginas web, ie. el administrador de la
> compañía se llama Carlos bergero, usuario cbergero es como dicen los
> americanos an educated guess :D
> Esto sin duda facilita el ataque, ahora bien.
> 2.- Por otro el ataque remoto da ventajas al atacante, si bien no es
> completamente cierto, le da un grado de impunidad o cobertura, no es lo
> mismo buscar a un ladrón que a punta de pistola robó a una viejita y le
> sacó la tarjeta con que cobra la jubilación y el PIN a golpes, que trazar a
> un hacker Ruso, que se robó los números de tarjeta y está vendiéndolos en
> Internet.
> 3.- Por último veremos que si bien las claves de una casilla de mail
> tienen la potencialidad de ser más fuertes en muchos casos son más
> atacables que los PINs de los cajeros que son teóricamente más débiles.
>
> Como vimos antes, los cajeros que utilizan PIN después de 3 intentos o
> fallos de ingreso del pin retienen la tarjeta, esto si no me equivoco es un
> standar internacional.
> Los correos y servicios ssh no suelen tener este tipo de protecciones si
> bien es muy fácil implementarlas, un ejemplo de esto es fail2ban un paquete
> de Linux, que permite bloquear direcciones IPs desde las que se están
> realizando ataques de fuerza bruta, por otro lado, y ya hace tiempo el
> servicio de ssh tiene un timeout de repregunta cuando se falla la clave.
> A nivel de correo, ya sea por medio de clientes web, o utilizando
> protocolos SMTP, IMAP o POP, se pueden implementar las mismas opciones de
> fail2ban. con lo que los ataques de potenciales 3 billones de claves por
> segundo usando un GPU, son bueno, irreales en la práctica.
> Ha me olvidaba, para el caso del ssh, en Linux es muy fácil configurar al
> servidor para que solo permita el login de algunos usuarios y en general
> como norma se debería deshabilitar el login de root.
>
> Creo que es claro que un ataque de fuerza bruta esta "condenado" a fallar,
> en la casi totalidad de los casos.
> ¿Entonces cual es la vida útil de una clave?
> Creo que la respuesta esta pregunta esta en esta otra pregunta, ¿A que
> tipo de ataques está sometida clave, o puede ser sometida?
> Si trabajamos en una oficina populosa y nunca tenemos idea de quien puede
> estar parado a nuestras espalda, o no tenemos control administrativo sobre
> los equipos que usamos y no confiamos en las personas que se hacen cargo de
> ellos, tal vez deberíamos considerar rotar las claves con cierta
> frecuencia. Si además se trata de claves "compartidas" se agregan otros
> factores a tener en cuenta, rotación del personal, exposición etc.
>
> Por último que ventaja nos da estar cambiando la clave cada x meses, desde
> el punto de vista de un ataque por fuerza bruta, no brinda ninguna
> protección o ventaja, salvo en el caso poco probable de que se cambie la
> clave por una que el atacante ya probó o por una que se encuentre "más
> lejos" en los parámetros de búsqueda del atacante, en cualquier caso este
> tipo de ataques deberían fallar automáticamente y/o ser trazables con gran
> facilidad.
> En el caso en que brinda "seguridad" es para los casos en que alguien en
> el entorno cercano del usuario blanco, está intentando activamente snoopear
> o deducir la clave  de este y aun en ese caso debería ser posible
> identificar esta situación por medios de control como los expuestos antes.
>
> No se si después de escribir tanto se entiende, pero creo que hoy en día
> el largo de las claves o su complejidad son irrelevantes, y deberíamos
> enfocarnos en otros problemas, más cerca o directamente en capa 8.
> Los mails clamando ser del área de TI se han sofisticado mucho en los
> últimos años, actualmente hacen referencia a las áreas de TI correctas y
> piden la información en el Lenguaje del país, y aun hoy muchos usuarios
> envía su usuario y clave por mail a estas consultas,
> Conozco el caso reciente de una persona que así lo hizo, causando el
> colapso del servidor de mail y web de la institución, lo gracioso es que su
> clave era a, si si la letra a, pero no fue necesario obtenerlo por fuerza
> bruta, ya que el la envió por mail, y probablemente un ataque por fuerza
> bruta habría obviado esta clave.
>
> Bueno espero no haber aburrido mucho a los que se tomaron el trabajo de
> leer hasta aca, gracias y nos vemos!!!
>
>
> Saludos,
>                 Carlos
>
> El 15/11/11 11:05, ksha nargaroth escribió:
>
> Carlos y Daniel,
>
> Creo que el problema es un poco mas amplio y lo plantearia de la siguiente
> manera.
>
> ¿Por cuanto tiempo tu contraseña sera segura?
>
> Si te enfocas de esa manera probablemente encuentren algo que los ayude un
> poco, de momento yo no me confio mucho
> ni en el sistema que encripte o cifre la informacion, ya que siempre se ha
> visto que solo es cosa de tiempo. Ahora recomendaria
> no usar password si no que frases lo mas larga posible y entre mas
> combinadas es mejor.
>
> Saludos.
>
> El 22 de septiembre de 2011 08:18, Carlos Bergero <rak en fcien.edu.uy>escribió:
>
>> Creo que el punto clave es precisamente l última frase que pusiste entre
>> paréntesis, a un atacante el obtener acceso a un sistema le representa un
>> costo X, esto se aplica, para el niño aprendiz de Hacker que trata de
>> entrar al servidor abandonado de su liceo o de la facultad de su hermano
>> mayor, o al "Black Hat Hacker" "profesional" que quiere robar una serie de
>> cuentas de un banco, tanto uno como otro tarde o temprano les va a salir
>> demasiado "caro", ie se va a aburrir/desmotivar/frustrar, con lo que cada
>> layer de "seguridad" o "dificultad" al acceso suma a ese costo.
>>
>> Saludos,
>>             Carlos
>>
>> El 22/09/11 08:47, Daniel Espejel escribió:
>>
>>  En un ataque de fuerza bruta,si puede procesar cada 1 segundo 1
>>> contraseña (entendiéndose como una permutación del espacio en cuestión),
>>> es como se realizan algunas estimaciones meramente didácticas.
>>>
>>> Pero,el poder de cómputo es un factor que influye mucho en el tiempo que
>>> se tarde...aún así,con algoritmos de cifrado más avanzados y una
>>> "contraseña fuerte" se pretende disuadir al posible atacante a utilizar
>>> alguna otra clase de métodos,ya que resulta en algunos casos
>>> computacionalmente inviable por la cantidad de recursos que hay que
>>> invertir ("que los gastos de atacar sean mayores que los beneficios que
>>> se obtienen al hacerlo con éxito").
>>>
>>> Saludos
>>>
>>>
>>   _______________________________________________
>> Seguridad mailing list
>> Seguridad en lacnic.net
>> https://mail.lacnic.net/mailman/listinfo/seguridad
>>
>
>
>
> --
>
> --
> Correo no firmado o cifrado
>
>
>
> _______________________________________________
> Seguridad mailing listSeguridad en lacnic.nethttps://mail.lacnic.net/mailman/listinfo/seguridad
>
>
>
> _______________________________________________
> Seguridad mailing list
> Seguridad en lacnic.net
> https://mail.lacnic.net/mailman/listinfo/seguridad
>
>

-- 
Luis Solís
Fono 032406262 - Cel 098355504
Ambato - Ecuador
------------ próxima parte ------------
Se ha borrado un adjunto en formato HTML...
URL: <https://mail.lacnic.net/pipermail/seguridad/attachments/20111115/54716c40/attachment.html>