<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
Es una buena pregunta, ¿Por cuanto tiempo tu contraseña sera segura?<br>
Yo diría que esto es dependiente del entorno en el que estás.<br>
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.<br>
Otro ejemplo puede ser, mi clave de facebook.<br>
O mi clave de usuario en linux en el servidor xyz.<br>
Todas estas son claves/contraseñas, pero están en entornos muy
distintos, así que analicemos un poco las cosas,<br>
<br>
Caso 1 PIN del cajero.<br>
Para poder atacar el PIN de mi cajero primero tiene que hacerse con
mi tarjeta, esto abre un abanico de opciones.<br>
<br>
Copia de la tarjeta.<br>
* 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ó.<br>
* 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.<br>
+ 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)<br>
<br>
Robo de la tarjeta.<br>
* 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.<br>
Perdida de la tarjeta.<br>
La perdida de tarjeta, sufre el mismo ataque que la copia en el caso
de que no se puede snoopear el PIN.<br>
<br>
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.<br>
<br>
Con respecto a los otros dos casos comparten una serie de
características comunes,:<br>
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<br>
Esto sin duda facilita el ataque, ahora bien.<br>
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.<br>
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.<br>
<br>
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.<br>
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.<br>
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.<br>
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.<br>
<br>
Creo que es claro que un ataque de fuerza bruta esta "condenado" a
fallar, en la casi totalidad de los casos.<br>
¿Entonces cual es la vida útil de una clave?<br>
Creo que la respuesta esta pregunta esta en esta otra pregunta, ¿A
que tipo de ataques está sometida clave, o puede ser sometida?<br>
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.<br>
<br>
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.<br>
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.<br>
<br>
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.<br>
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,<br>
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.<br>
<br>
Bueno espero no haber aburrido mucho a los que se tomaron el trabajo
de leer hasta aca, gracias y nos vemos!!!<br>
<br>
<br>
Saludos,<br>
Carlos<br>
<br>
El 15/11/11 11:05, ksha nargaroth escribió:
<blockquote
cite="mid:CAO--v25wZa5+ioeogMUqpxwTZqhfSiK+K40TY=jTZNZoGgQE5w@mail.gmail.com"
type="cite">Carlos y Daniel,<br>
<br>
Creo que el problema es un poco mas amplio y lo plantearia de la
siguiente manera.<br>
<br>
¿Por cuanto tiempo tu contraseña sera segura?<br>
<br>
Si te enfocas de esa manera probablemente encuentren algo que los
ayude un poco, de momento yo no me confio mucho<br>
ni en el sistema que encripte o cifre la informacion, ya que
siempre se ha visto que solo es cosa de tiempo. Ahora recomendaria<br>
no usar password si no que frases lo mas larga posible y entre mas
combinadas es mejor.<br>
<br>
Saludos.<br>
<br>
<div class="gmail_quote">El 22 de septiembre de 2011 08:18, Carlos
Bergero <span dir="ltr"><<a moz-do-not-send="true"
href="mailto:rak@fcien.edu.uy">rak@fcien.edu.uy</a>></span>
escribió:<br>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex;">
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.<br>
<br>
Saludos,<br>
Carlos<br>
<br>
El 22/09/11 08:47, Daniel Espejel escribió:
<div class="im"><br>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
En un ataque de fuerza bruta,si puede procesar cada 1
segundo 1<br>
contraseña (entendiéndose como una permutación del espacio
en cuestión),<br>
es como se realizan algunas estimaciones meramente
didácticas.<br>
<br>
Pero,el poder de cómputo es un factor que influye mucho en
el tiempo que<br>
se tarde...aún así,con algoritmos de cifrado más avanzados
y una<br>
"contraseña fuerte" se pretende disuadir al posible
atacante a utilizar<br>
alguna otra clase de métodos,ya que resulta en algunos
casos<br>
computacionalmente inviable por la cantidad de recursos
que hay que<br>
invertir ("que los gastos de atacar sean mayores que los
beneficios que<br>
se obtienen al hacerlo con éxito").<br>
<br>
Saludos<br>
<br>
</blockquote>
<br>
</div>
<div>
<div class="h5">
_______________________________________________<br>
Seguridad mailing list<br>
<a moz-do-not-send="true"
href="mailto:Seguridad@lacnic.net" target="_blank">Seguridad@lacnic.net</a><br>
<a moz-do-not-send="true"
href="https://mail.lacnic.net/mailman/listinfo/seguridad"
target="_blank">https://mail.lacnic.net/mailman/listinfo/seguridad</a><br>
</div>
</div>
</blockquote>
</div>
<br>
<br clear="all">
<br>
-- <br>
<br>
--<br>
Correo no firmado o cifrado<br>
<br>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
Seguridad mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Seguridad@lacnic.net">Seguridad@lacnic.net</a>
<a class="moz-txt-link-freetext" href="https://mail.lacnic.net/mailman/listinfo/seguridad">https://mail.lacnic.net/mailman/listinfo/seguridad</a>
</pre>
</blockquote>
<br>
</body>
</html>