Sigue El lado del mal en Telegram
Chema Alonso en Threads
Chema Alonso en Mastodon
Chema Alonso en BSKY
Chema Alonso en Linkedin
DragonJAR
8.8 Chile
Ekoparty
e-Hack MX 
AREA 51 
Comunidad Dojo Panamá 
ARPAHE SOLUTIONS 
¿Se deben usar passwords complejas en la web?
Hace un tiempo escribí un artículo titulado "Hay que acabar con las passwords complejas en los servicios online" en el que venía a explicar por qué creo que el recomendar masivamente a los usuarios que pongan contraseñas complejas en cualquier página web que se registra no tiene sentido.
 |
| Figura 1: Gestión de contraseñas complejas |
En aquel artículo recogí mis pensamientos sobre tres ideas principales.
1) Las passwords complejas no defienden de la mayoría de los ataques.
2) El usuario no puede ser el responsable de toda la medida de seguridad/inseguridad. Es decir, no podemos dejar que el usuario sea el determinante de la seguridad como dije en "Mea Culpa, Penny".
3) La mayoría de las medidas de seguridad deben caer de manos del servidor.
En aquel momento no había leído aún algunos trabajos académicos, pero con el tiempo fui descubriendo que a esta conclusión que yo había llegado por mi propia experiencia, hace tiempo que había sido estudiada y documentada en varios artículos que hoy os paso a dejar por aquí.
[1] ¿Sirven para algo las passwords complejas en la web?
Este primer documento recoge la primera de las tres ideas que use como argumento. La mayoría de los ataques que se utilizan en el robo de identidad no se ven afectados para nada si la contraseña es o no compleja. Que sea una password compleja o que no lo sea da exactamente igual.
 |
| Figura 2: ¿Sirven para algo las passwords fuertes en la web? |
[2] El esfuerzo finito en la gestión de contraseñas que se le puede pedir a un usuario
Este segundo trabajo está centrado en la premisa de que si la seguridad de tu sistema depende de que el usuario haya elegido passwords complejas ese es un escenario poco realista, ya que el esfuerzo de los usuarios es finito y hay, por tanto, que identificar qué grupos de cuentas son en las que se puede exigir una password compleja y en cuál hay que asumir que no. Interesante.
 |
| Figura 3: El esfuerzo finito de los usuarios en su seguridad |
[3] Las medidas deseguridad del sitio para no hacer necesarias las passwords complejas
En el artículo que yo escribí, decía que debía ser el sitio web el que ofreciera suficientes medidas de seguridad para hacer que las passwords no tuvieran que ser complejas, ya que las identidades estarían protegidas. La lista de medidas que yo enumeré fueron:
a.- Usar un segundo factor de autenticación.
b.- Evitar ataques de fuerza bruta a la password
c.- Evitar ataques de fuerza bruta al usuario
d.- Almacenamiento robusto de contraseñas
e.- Cifrado robusto end-to-end
En el último trabajo de Microsoft que os cito, se vuelve a hablar del poco sentido que tienen las passwords complejas en la mayoría de los escenarios, y lo acaban resumiendo con este cuadro en el que en cada situación, al final, da igual que la password sea compleja o no.
 |
| Figura 4: ¿Dónde ayuda algo una password compleja? |
Solo en el caso del Offline Guessing Attack cuando el fichero ha sido obtenido por el atacante y el administrador del sitio no lo ha detectado es cuando una contraseña compleja gana algo de tiempo, pero no mucho más.
Al final, si gestionas una larga base de datos de usuarios online, poner un segundo factor de autenticación y una contraseña - como Latch, Verificación en 2 Pasos vía SMS o Google Authenticator - sencilla ayudará al usuario a estar más seguro, a no olvidarse la contraseña y generar problemas de soporte, y beneficiará tanto a la usabilidad como al negocio en general.
Saludos Malignos!
18 comentarios:
Yo creo que en vez de emplear contraseñas de 8 caracteres raros, es preferible usar 4 palabras seguidas que son mucho más fáciles de recordar: aunque el alfabeto disminuye la longitud compensa.
Recordatorio:
El Honda Civic de mi hermano es rojo pero está accidentado.
Contraseña_ Hondahermanorojoaccidentado
P.D. Ya sabemos que Latch es la ostia como segundo factor de autenticación ;)
Es totalmente razonable, varias empresas han implementado la doble verificación, la última Apple y es más fácil para el usuario final, así debe ser antes que escribir en una libreta tus passwords complejas, por que al fin y al cabo como se muestra en el esquema de Microsoft, todas las posibilidades están previstas.
No todo es denunciar vulnerabilidades pero las soluciones también se pueden proponer en igual medida, es parte del proceso, como el caso para Latch y es que en mi hulmide opinión, sondeando un poco no veo más ideas como esta, tampoco creo que hayan sido promocionadas o lanzadas con éxito, al menos en este país, tanto a empresa como para el usuario final que lo quiera utilizar. Así que resulta más positivo que negativo en mi balanza.
No, no se deben usar "passwords", se deben usar contraseñas joder, que es una palabra preciosa.
Estoy de acuerdo en que la complejidad de la contraseña no suele incrementar su seguridad, pero hay una medida que todo usuario debería tomar: nunca reutilizar contraseñas.
Si se reutilizan contraseñas, cualquier registro que hagamos en un servicio poco seguro puede comprometer la seguridad de otros servicios.
Chema, qué opinas de servicios como Lastpass?
Interesante artículo pero es cierto que al final por muy compleja que sea la clave hay forma de conseguirla, aunque sea alfanumérica y no lógica. Yo suelo al menos generar claves con 1password o con http://password.es/
Si se usa encriptación reversible, si es un algoritmo de encriptación asimetrico y se obtiene la clave pública, se estaria en el mismo caso que el de hashing, no?
Y una clave sencilla hace que sea mas probable que esté en una Rainbow Table, no?
Interesante la reflexión, pero matizaría algunas cosas:
-Utilizar contraselas complejas implica no utilizar contraseñas fáciles de adivinar, tanto si conoces al susodicho (nombre de la mascota, fecha del nacimiento de los hijos), como si no le conoces (123456, pasword1, Ronaldo y cosas por el estilo). E incluso si quieres hacer "shoulder surfing" también lo complica.
-Se dice "Solo en el caso del Offline Guessing Attack cuando el fichero ha sido obtenido por el atacante y el administrador del sitio no lo ha detectado". Bien, esto ya de por si es una mejora respecto a no tener una contraseña compleja. Además no solo es cuando el administrador no se de cuenta, también es hasta que el usuario se de cuenta y cambie la contraseña (que no siempre se fuerza el reseteo).
-Si fuera tan fácil como poner un doble factor de autenticación...la usabilidad se resiente. Parafraseando el primer parrafo del post "lo que no tiene sentido es recomendar masivamente la adopción de un segundo factor de autentiación".
En definitiva, de acuerdo en que los administradores tienen que plantearse si tiene sentido exigir contraseñas complejas a sus usuario en función de lo bien que tengan implementados los sistemas (hash, salt...). Y en mi opinión si estan bien implementados, que es lo que se debería exigir, la contraseña compleja aporta un extra de seguridad. Ahora bien, puede que no merezca la pena ese esfuerzo por parte del usuario en comparación con la seguridad que aporta. Pero me parece que en ese caso quien mejor podría hacer la valoración del equilibrio esfuerzo-seguridad es el propio usuario, el que sabe la información que esta protegiendo esa contraseña y las consecuencias que le supondra que comprometan la cuenta. Por lo tanto, en mi opinión la solución pasa, entre otras cosas, por la formación del usuario, por que sepa asignar diferentes niveles de seguridad a las web que utiliza y escoja las contraseñas buscando el equilibrio usabilidad-seguridad.
Interesante articulo, estoy totalmente deacuerdo, la fortaleza de una contraseña no se deberia medir en la longitud de la misma si no mediante otros parametros. Un segundo nivel de autenticacion veo que es la solucion mas fiable a dia de hoy, puesto que tarde o temprano, si consiguen las claves aun cifradas, podran realizar algun metodo para conseguirlas bien sea por RainbowTable o mediante metodos de descifrado de claves ( que segun va avanzando la tecnologia los tiempos por clave se acortas y muchoooo ).
¿De las "preguntas de seguridad" tipo "¿el nombre de mi osito de peluche?" ni hablamos, no? No entiendo como es posible que se usen en tantos sitios, es de risa. Me ha gustado el artículo.
Completamente de acuerdo con @Barmatal, si ponemos contraseñas fáciles y legibles, si un atacante se hace con nuestra contraseña es fácil deducir las de otros servicios. Muy buen artículo, yo uso segundo factor de autenticación en cada uno de los servicios que me lo permite. Saludos.
Chema, el link al paper: "[1] ¿Sirven para algo las passwords complejas en la web?" está roto.
Igual, por el título lo encontré: http://www.cs.umd.edu/~jkatz/security/downloads/StrongPasswordsDoNothing.pdf
Saludos.
Pues yo no estoy de acuerdo con la afirmación y ahora lo explico, porque creo que va en contra de la base de la seguridad en profundidad.
Como bien dice @Javier Dai, hay ataques de diccionario o directamente de fuerza bruta y ahí es justo donde una clave compleja se la juega, ese es un motivo para tener claves complejas. Ante un MiTM, ante un intento de fuerza bruta...
Otra forma de verlo, por reducción a lo absurdo, no es que permitamos claves sencillas, es que la quitamos directamente, que no se necesite. Como consecuencia estaríamos dejando la dificultad de autenticarse en el segundo facto de autenticación, que en este caso de reducción a lo absurdo sería único, con lo que sólo habría un factor de autenticación, que es justo lo contrario que estamos intentando.
Como esbocé antes, esto es defensa en profundidad, la clave tiene que ser compleja. Lo que no tiene sentido es fiar todo a la clave, se necesitaría un segundo factor, pero siempre que el segundo factor sea un segundo factor, no un primero. Yo no dejaría el acceso a mi web SÓLO en manos de Latch por ejemplo.
Que bien chema! Investigando en papers? No lo he visto antes en tu blog. Vas a hacer un PhD? Jeje.
Mi conclusión anticipada es que un password largo es más seguro que uno complejo, por esto del brute-force de sistemas inseguros. Nada más.
Saludos.
Mi conclusión final, es que no debería de delegarse todo al usuario, salta a la vista por los antecedentes acaecidos, que ni tienen ni van a tener los conocimientos mínimos, bien por no comprender esos mínimos o por que no les interesa.
Por mi parte, si puedo decir que toda opción que pueda poner una capa más de seguridad, sea doble verificación o Latch en los casos que hablamos, es viable y no tiene efecto contraproducente, siempre y cuando estás conforme y has leído ,los detalles del acuerdo de servicio al activarlo :P
Ni sólo confiaría el acceso a mis servicios a una password que yo pudiera interpretar como robusta, ya no como dijeron más arriba en los comentarios, además de evitar contraseñas de histórico, si no sistemas personales con un patrón definido, el apuntarlas en la nube, quien habrá que lo haga. Toda opción que añada una capa más de seguridad, es viable siempre y cuando, comprendes todo lo demás.
Entiendo que esto es visto desde el lugar del informático que da soporte a una aplicación en particular, poniendo sobre la balanza si incorporar un doble factor o sólo confiar en una contraseña larga y compleja.
Pero también tenemos que ponernos desde el punto de vista del usuario modelo, que accede a no menos de 10 sitios donde se le requiere autenticación (mínimo). Si se le requiere sólo contraseña, y conociendo los últimos eventos donde se utilizó fuerza bruta, entonces no queda otra que usar contraseñas fuertes y largas. Si se le hubiera requerido doble factor estaría solucionado el problema puntual de ataque de fuerza bruta, independientemente de la fortaleza de la clave. (contraseñas 0 - doble factor 1).
Pero el tema es que el doble factor, factor es desconocido aún por muchos usuarios, utilizado por personas que son más paranoicas, posiblemente las mismas que usan además una clave compleja y larga, por lo que si se le da a elegir al usuario, preferiría no contar con un doble factor (por el momento). (contraseñas 1 - doble factor 1).
Otro tema a considerar es la fuga de las contraseñas, ya sea hasheadas, con salt o en claro de proveedores MUY importantes, donde uno confió la protección de su contraseña y se vió defraudado por la falta de medidas. En este caso, como usuario de ese servicio, al menos estuve tranquilo que al haber elegido una clave compleja y larga, por más que se hayan fugado los archivos de claves, no podían descubrir la mía, y además, de haber sido, no pudieran deducir otras.(contraseñas 2 - doble factor 1).
Por último, si confiamos en la utilización de doble factor, tendríamos que suponer que existe en todos los sistemas, ya que si el usuario se acostumbra a utilizar una clave no tan fuerte en pos de un doble factor, pero esto sólo se aplica a una minoría, el usuario terminaría usando claves débiles casi siempre, y estando seguro casi nunca, porque los servicios con doble factor aún no son mayoría.(contraseñas 3 - doble factor 1).
Por último, les comento que uso doble factor mientras esté disponible (soy partidario de su uso) y además claves complejas. Estas últimas las gestiono a través de un gestor de claves MUY simple. Que sirve para descargar al usuario de la responsabilidad de saber tantas claves complejas.
Si todos los sistemas donde accedo tuvieran doble factor lo usaría, pero seguiría usando contraseñas complejas gestionadas por un software, ya que no me fío de los mecanismos implementados para proteger nuestra identidad por los proveedores. Con esto sólo quiero indicar que la protección de nuestra identidad debería ser responsabilidades de ambas partes, y que el usuario ser consciente de los riesgos que se expone en cada caso, ya que actualmente los proveedores de servicios están dejando mucho que desear...
Yo el lach no lo veo ni de lejos... Es como pedirle a un crío que cada vez que salga del portal del edificio eche la llave... (No lo hará nunca). En cambio en mi edificio opté por la vía lógica, si lo hace una máquina que no lo haga el hombre, tengo cerraduras que se auto arman al cerrar la puerta y pasan el bulon con la ventaja que aparte de por proximidad y con llave, desde la vivienda o el sistema contra incendios sé abren (con Backup de batería).
Para mi el sistema va estar óptimo va a estar vinculado al modelo Apple Pay y el uso del iPhone, iPad o el Watch que se encargarán de generar nuestra clave (certificado) único al darnos de alta y guardaran las versiones encriptada que le devuelva el servicio (certificado) que junto con un OTP generará un clave compleja única para cada sesión en cada aplicación o web y que será trasmitida por BLE encriptada al equipo y adiós a escribir claves, dejar que las recuerde el ordenador, acordarse uno o tenerlas repetidas, será una por sesión y aplicación.
Y lo mismo que la puerta estará siempre cerrada con bulon pero abrirla será más sencillo que la cerradura normal sin estar pasado el bulon.
Lo demás son parches que dan sensación de seguridad, es una falsa segurídad en la realidad.
@Alfonso C. Betancort, Latch permite al dueño del sitio cerrar vía API el latch de sus clientes automáticamente vía automatismo para que no se quede abierto, y al usuario usar autolock.
Por otro lado, Apple Pay es un sistema de autenticación que hace la negociación basándose en un sistema previamente autenticado, que debe resolver la autenticación previamente. De momento Apple lo ha resuelto solo para su Apple Pay en Apple.
FIDO está trabajando en hacer otros sistemas. Todos esos resuelven problemas de autenticación, pero Latch es un Segundo Factor de Autorización que va más allá por flexibilidad y usabilidad que otros sistemas.
Saludos!
Publicar un comentario