Para quienes se venían regocijando con mis desventuras, les traigo otra historia parecida y el aprendizaje.
Lo que ocurrió fué que en medio de una difusión pública, pasando de una ventana a otra, quedó expuesto un documento con credenciales. Aunque la persona rápidamente notó el error y sacó el documento, obviamente era tarde, pues en la virtualidad es muy sencillo desplazarse hacia atrás en el tiempo y pausar.
Fue interesante notar que la clave, aunque era larga, tenía un importante defecto, que es que era legible al estar compuesta por palabras. Esto no es tan malo en sí, lo es por que nos da un fuerte indicio de cómo puede estar conformada esta misma clave en el futuro o en sistemas cercanos.
Es como si mi regla de claves de web mails fuera:
proveedorAñoPalabra
En particular
gmail2007canulos
Como que para atacarme en yahoo voy a probar con
yahoo20##xxxxxxx
Esta clave me da un nuevo concepto que voy a llamar "Falsa sensación de usabilidad", que es amigo de "Falsa sensación de seguridad", pero, como es evidente, desde el punto de vista de UX.
Comparando gmail2007canulos con dbHg96Pecfdu86ev sin duda la primera es más fácil de recordar y en caso de tenerla escrita o en un dispositivo distinto al de uso, de transcribir a mano, cosa para lo que la segunda no se presta
La probabilidad y estadística y la teoría de la información no es lo mío, pero intuitivamente puedo apreciar las medidas de las claves según varias fuentes:
[1] | [2] | [3] | |
---|---|---|---|
dbHg96Pecfdu86ev | 3.625 | 73.521 | 78.3 |
aaaaaaaaaaaaaaaa | 1 | 5 | 66.7 |
gmail2007canulos | 3.625 | 42.054 | 62.8 |
Los numeritos cuanto mayores mejores.
¿Como que no es tan malo el que teníamos, no?
No, es muy malo, por que ya conocemos gmail2007, nos queda:
canulos | 2.80735 | 16.04 | 24.1 |
Si no necesitamos recordar, podemos elegir la primera. Si necesitáramos poder escribirla pues la tenemos en papel u otro dispositivo y el login en otra, debemos tener la precaución de no usar ciertas letras. Esto debilita levemente la clave pues reduce la combinaciones a explorar pero excluye los problemas de lectura como:
1l
0O
6G
Si no te parece importante, te desafío a que en un sistema de tres intentos no te bloquees con esto:
Acá podemos ver el diálogo de creación de una entrada en un gestor[4] de claves, es la una opción ("exclude look-alike characters"):
Tambien se podrían agregar delimitadores para facilitar la lectura:
dbHg96Pecfdu86ev
dbHg.96Pe.cfdu.86ev
dbHg-96Pe-cfdu-86ev
dbHg_96Pe_cfdu_86ev
Estos delimitadores mejoran la resistencia ante un ataque de fuerza bruta. Para quien conoce nuestro esquema sólo triplica el tiempo de exploración.
Una vez que hemos llegado a guardar las credenciales en un gestor, si difundimos accidentalmente, sólo relevamos en qué sitios tenemos cuentas, que no es tan grave y el usuario, que sería mejor no divulgarlo tampoco, pero dista de las credenciales.
Por lo general los sitios y usuarios podemos considerarlos información pública, ya que basta con entrar en esos sitios para ver nuestros aportes e identificarnos. Es por ello que es en extremo importante proteger lo realmente secreto, que es lo único secreto, la clave.
Como el gestor permite copiar en el portapapeles la clave sin verla, en ningún momento hay riesgo de que pueda divulgarse. Al cabo de diez segundos se borra del portapapeles, así que la oportunidad de pegarla accidentalmente en otro lado que no sea el campo de autenticación es baja.
Concluyendo, el procedimiento de respuesta dicta que al menos hay que:
- Cambiar la clave en el sistema afectado.
- Evitar que el video quede online.
- Cambiar la clave en el documento.
- Notificar a los usuarios de esa clave si los hay.
- Editar el video.
- Publicar el video según lo planeado.
El procedimiento de prevención agrega que:
- Sacar la clave de documento y ponerla en un almacén, por ejemplo keepass.
- Usar una clave generada al azar de no menos de 16 caracteres.
- Intentar recordar cerrar los documentos y aplicaciones sensibles antes de iniciar una difusión pública.
Sólo nos resta tener una clave muy fuerte y recordable para el gestor, usando una técnica como la de https://xkcd.com/936/
No estoy de acuerdo con las cuentas ahí expuestas, pues siempre debo asumir que si tengo un esquema de claves, el adversario lo conoce, pues al usarlo en distintos sitios, alguno puede haber sido vulnerado.
No es:
correcthorsebatterystaple | 3.36386 | 49.495 | 93.6 |
65 ^ 25 -> 1.4272477e+45 combinaciones
es (palabras en el diccionario) ^ 4, siendo diccionario un número bajo:
si fuera 2000 -> 1.6e+13
si fuera 10000 -> 1e+16
igual es un poco mejor que canulos (65^7 -> 4.9022279e+12).
canulos | 2.80735 | 16.04 | 24.1 |
Te invito a reflexionar sobre el tema, hacer las cuentas y corregirme si me equivoqué en ellas o los conceptos.
[1] http://www.shannonentropy.netmark.pl/
[2] https://apps.cygnius.net/passtest/
[3] http://rumkin.com/tools/password/passchk.php
[4] algunos gestores
https://www.keepassx.org/
https://keepass.info/
No hay comentarios:
Publicar un comentario