@kastwey @Javichi En teoría cada actor de ActivityPub debe tener su propia clave. Supongo que hay software the instancias que usan una sola para la instancia entera pero en el caso de GTS por ejemplo sé que cada usuario tiene la suya. Pero no sirve de nada si está en el control del servidor, y por otra parte como lo de guardar claves es magia, pues nada, así nos va.
@kastwey @modulux @Javichi Lo jodido muchas veces es que los gestores de contraseñas no te dejan meter frases demasiado largas. Por cierto que hay un estudio reciente que dice precisamente que las contraseñas raras, que obligan a meter números, mayúsculas y minúsculas, etc., en realidad son perjudiciales para la seguridad, porque la gente las apunta en algún sitio para recordarlas
@modulux @kastwey @Javichi Efectivamente, esa era otra de las cosas que decían en ese estudio, que obligar a la gente a cambiar de contraseña con demasiada frecuencia era contraproducente, lo que recomendaban eran contraseñas consistentes en frases, que son relativamente fáciles de recordar y muy difíciles de descifrar
@kastwey @tinitun @Javichi En el trabajo tenemos una regla de reemplazo que manda huevos, además porque invita racionalmente a pensar que las guardan en claro.
Además de lo típico (no contener el nombre de usuario, no repetir la anterior) no puede tener una distancia de Levenshtein igual o inferior a 3.
O sea, hay que cambiar, añadir o suprimir más de 3 caracteres.
Tampoco puede ser una rotación, tipo contraseña, ontraseñac.
@tinitun @kastwey @modulux @Javichi De hecho por fin el NIST recomienda prácticas con sentido. Ha salido hace poco el nuevo boceto de recomendaciones y para las contraseñas, entre otras cosas dicen...
Que acepten contraseñas de más de 16 caracteres, recomendando por lo menos 64
Que no se impongan reglas de composición por tipos de caracteres
Que no requieran cambios de contraseñas periódicos (pero que fuercen los cambios de contraseñas si se demuestra que están comprometidas)
Que no se usen preguntas de seguridad (por fin, ya era hora, no entiendo como Microsoft siguen haciendo eso)
He hecho un paseo rápido por las recomendaciones y en general me han parecido bastante buenas. Y lo bueno es que, si aparecen en la guía del NIST, las empresas estadounidenses que quieren hacer determinados trabajos de con el gobierno o entidades grandes, tienen que cumplirlas. Y eso va permeando al resto.
Aparte, también te da una excusa para cumplirlo tú en un proyecto. "Lo siento pero estamos usando la guía SP 800-63-4 del Instituto Nacional de Estándares y Tecnología, no puedo hacer que el software te pregunte tu apellido de soltera para recuperar tu contraseña."
@andor @tinitun @kastwey @Javichi Todas ellas reglas racionales. sin embargo, hasta donde yo sé, ENISA continúa recomendando cambios periódicos de claves.
El tema de las preguntas de seguridad es interesante, sobre todo porque aunque no sean un mecanismo muy fiable tampoco tengo muy claro que otros mecanismos de recuperación pueden funcionar bien. Lo de que te manden un correo, vale, pero si es la clave de la cuenta de correo ya tenemos un pequeño gran problema, por ejemplo.
@tinitun @modulux @andor @Javichi No no, no se puede, pero se podría, y creo que molaría mucho. Que los grandes proveedores confiasen en los certificados raíz de autoridades como FNMT, certcat y demás, y que si el usuario introduce su documento de identidad como parte de la configuración del correo, se pudiesen usar esos certificados para iniciar sesión o recuperar la clave.