Divulgación: trabajo para AgileBits, los creadores de 1Password. También escribí sobre esta misma pregunta en nuestro blog [1] en 2013. Si bien mi respuesta sigue en pie y se superpone en gran medida con lo que respondo aquí, creo que han cambiado suficientes detalles y contexto que es valioso para mí responder esto De nuevo aquí.
No puede saber con absoluta certeza, pero hay varias cosas que puede observar para aumentar su confianza en que un administrador de contraseñas está haciendo lo que dice.
En primer lugar, las personas no pueden regalar información que no tienen. Como me gusta decir, no podemos perder, usar o abusar de datos que nunca tenemos.
- ¿Qué tipo de educación necesita para convertirse en un vendedor profesional en las empresas de seguridad de la información?
- ¿Podría haber ocurrido el error Heartbleed si OpenSSL se hubiera escrito en Rust?
- ¿Es cierto que China es buena en ciberataques?
- ¿Cuál es una manera efectiva de protegerse del criptoanálisis con manguera de goma?
- ¿Es cierto que los investigadores recientes de seguridad cibernética desarrollan WannaCry reciente y otro tipo de malware para aumentar su demanda de trabajo y su mercado?
¿Qué información puede recopilar un sistema en particular?
Si el comportamiento alegado de un administrador de contraseñas es un documento suficientemente bueno (tal vez a través de una fuente publicada, tal vez no), debería ser posible verificar al menos en el lado del cliente que el comportamiento se ha prometido.
Los sistemas que ofrecen o permiten algún tipo de sincronización de datos transmiten información a la nube (también conocida como “computadora de otra persona”). Entonces, cuando se trata de este comportamiento, hay varias preguntas que hacer
- ¿Qué datos transmitidos están y no están encriptados?
Por ejemplo, el antiguo formato de llavero ágil de 1Password no cifraba los títulos de los artículos y la información de ubicación. (Esto fue reemplazado por nuestro formato de datos OPVault años, pero me siento más cómodo hablando de este tipo de comportamiento en nuestros propios sistemas que en la competencia).
Asegúrese de tratar de distinguir entre cifrado y mera ofuscación en esto. Una vez más, el diseño Agile Keychain anticuado no ocultó los datos no cifrados; en cambio, documentamos para nuestros usuarios e investigadores de seguridad qué datos estaban y no encriptados.
Puede darse el caso de que, si bien algunos sistemas no pueden aprender sus contraseñas, pueden aprender sus hábitos de navegación y saber cuándo inicia sesión en sitios particulares. Aunque esos datos pueden no ser tan valiosos para el FBI, todavía es algo que podría venderse. (Por cierto, esta preocupación por la privacidad es la razón por la que no recomiendo los sistemas de inicio de sesión único que ofrecen Facebook, Google o Twitter).
- ¿A dónde van esos datos?
Puede monitorear y examinar su propia actividad de red. Con herramientas como burbsuite puedes hacerlo con gran detalle para ver exactamente qué va a dónde.
¿Qué tan “de extremo a extremo” es el cifrado?
El cifrado solo lo protege contra un proveedor malicioso o comprometido si es un cifrado de extremo a extremo . Esas son las claves secretas que se utilizan para cifrar sus datos que deben crearse en el sistema del usuario y nunca dejar esos sistemas sin cifrar. Obteniendo la redacción correcta de esto porque hay claves que cifran claves (que cifran claves). Pero espero que sepas a qué me refiero: hay secretos que nunca dejan el dispositivo del usuario que son necesarios para descifrar los datos.
Pero el cifrado de extremo a extremo no es suficiente si las claves de descifrado se derivan de secretos de usuario adivinables, como las contraseñas maestras. Hemos construido 1Password con lo que llamamos derivación de clave de dos secretos (2SKD). En términos generales, la contraseña maestra del usuario se combina (y esto es todo del lado del cliente) con un secreto de usuario de alta entropía en el dispositivo del usuario. Esto significa que los datos que almacenamos en nuestros servidores no se pueden usar en un intento de descifrado de contraseña. [2]
¿Cómo se protege el software del cliente?
Todo este cifrado de extremo a extremo utilizando claves derivadas de secretos de usuario de alta entropía es excelente para defenderse contra un ataque del lado del servidor. Pero, por sí solo, no lo defiende contra el software malicioso del cliente.
Esto realmente es lo más difícil de probar seguro. Como otros han mencionado, las soluciones de código abierto son útiles aquí, pero a menos que el software se produzca con compilaciones deterministas o compile usted mismo, no puede saber que el binario que ejecuta en su máquina se ha producido a partir de la fuente publicada.
Nuevamente, su mejor defensa es la documentación explícita sobre cómo se comporta el software (y el código abierto es una forma de ser muy explícito, pero no la única) para que las personas puedan verificar que el software se comporta como está documentado. Nuevamente, no necesitamos que cada individuo que use el software lo examine con tanto detalle. Solo necesitamos que haya suficientes personas que lo hagan para que se note cualquier desajuste.
Esto reduce el alcance de la modificación maliciosa en el software del cliente, pero no lo elimina. Por ejemplo, si un atacante modificara el generador de números aleatorios que se usa para crear las claves criptográficas, sería muy difícil detectarlo simplemente mirando las entradas y salidas del software. Pero lo que esto hace es que limita drásticamente los lugares en el software en los que se podría insertar dicha puerta trasera, lo que facilita su detección.
Si utilizamos una arquitectura de seguridad que reduce los lugares donde podría ir una puerta trasera, haremos que sea más difícil que no sea detectada por aquellas personas que tienen acceso de lectura a la fuente. También he escrito sobre arquitecturas de seguridad y puertas traseras [3].
Detectando el mal
A lo largo de todo esto, no he hablado de lo que dificultaría ser malvado, sino de lo que dificultaría que tal maldad no sea detectada. Los argumentos generales son que un buen diseño y apertura sobre ese diseño dificultan que una puerta trasera pase desapercibida.
Cui bono?
La pregunta se refería a los administradores de contraseñas “freemium”. No creo que eso importe demasiado en sí mismo, pero plantea el punto final. ¿Le interesaría al desarrollador abrir un administrador de contraseñas? Entonces, incluso si estuviéramos inclinados a ser malvados (no lo somos, pero no tienes forma de saberlo), ¿qué ganaríamos y perderíamos de ser malvados?
En nuestro caso [creadores de 1Password], tendríamos muy poco que ganar al ser malvados y mucho que perder si se detectara tal maldad. Si fuéramos malvados y eso fuera detectado, estaríamos inmediatamente fuera del negocio. Ese es el sustento de más de 70 personas inmediatamente en juego.
Sin absolutos
Comencé diciendo que no podemos ofrecer pruebas o garantías absolutas . Pero nosotros y otras soluciones de administración de contraseñas se pueden evaluar y examinar en los tipos de términos que he descrito anteriormente. Naturalmente, creo que eso debería darle una confianza más que suficiente en varios administradores de contraseñas.
Notas al pie
[1] 1Password y The Crypto Wars
[2] 1Password es # LayerUp-ed con autenticación moderna
[3] Las puertas traseras son malas para la arquitectura de seguridad
