[Descargo de responsabilidad: trabajo para AgileBits , creadores de 1Password .]
Gracias por pedirme que responda esto, Ram Jothikumar. Me complace hablar sobre 1Password, pero no deseo decir ni implicar nada sobre ningún otro producto o servicio. Nosotros en AgileBits no tenemos acceso a ningún dato de 1Password.
La preocupación legítima que muchas personas tienen sobre el almacenamiento de sus datos en la computadora de otra persona es que quienes alojan los datos se verán comprometidos o que ellos mismos harán algo con los datos que preferirían que no hicieran.
- ¿Qué se considera conocimiento poco común sobre seguridad cibernética más allá de algunos de los hechos más conocidos en 2016?
- Con la vigilancia desenfrenada y la intrusión de gobiernos y corporaciones, ¿quiénes son algunas personas técnicas confiables que trabajan para garantizar que nuestra privacidad no sea quitada?
- ¿Cuáles son los inconvenientes de nessus como herramienta de seguridad de red?
- ¿Cuál es la autenticación más segura, antigua basada en token o JWT?
- ¿Es necesario un firewall para su sitio web?
Creamos un sistema que lo mantiene seguro contra nosotros. No es que nos preocupemos de convertirnos en malvados ni nada, sino que es el simple hecho de que si estás seguro contra nosotros, estás seguro contra cualquiera que nos comprometa.
1Password tiene un diseño de seguridad abierto. Hemos esbozado todo el diseño de seguridad de 1Password en un documento técnico [PDF], donde ha sido objeto de escrutinio por parte de expertos en seguridad.
Por supuesto, es posible que no esté en condiciones de analizar el libro blanco usted mismo, pero se beneficia del escrutinio que le dan los que pueden. Y me complace explicar lo que creo que son dos de los aspectos más importantes de la seguridad de 1Password de una manera más fácil de entender.
Lo que diferencia a 1Password de una perspectiva de seguridad es nuestro uso de la Derivación de clave de dos secretos (2SKD) y la autenticación de preservación del secreto.
Derivación clave de dos secretos
Imagine una violación en la que se capturan todos los datos que almacenamos. Para muchos sistemas, habría hashes o claves derivadas de una contraseña de usuario entre los datos robados, por lo que el atacante podría ejecutar un ataque de descifrado de contraseñas. Si tienen éxito en el intento de descifrar la contraseña, con esa contraseña (y algunos otros datos no secretos como sales, etc.) podrían descifrar los datos almacenados del usuario. Eso sería malo.
La defensa “tradicional” contra esto es usar hashing lento durante la derivación de claves. 1Password fue uno de los primeros administradores de contraseñas en usar PBKDF2, y ahora este o algún otro mecanismo de hash lento se ha convertido en una característica bastante estándar. Es bueno, es importante, todavía lo hacemos; Pero puede que no sea suficiente . Ralentiza a un atacante; pero no evita por completo los intentos de adivinar la contraseña maestra.
Lo que hemos hecho es presentar lo que llamamos Derivación de clave de dos secretos (2SKD). Mezclamos su contraseña maestra junto con un secreto de alta entropía que solo usted posee : su clave de cuenta. Su contraseña maestra es un secreto que vive solo en su cabeza, pero es potencialmente adivinable; y su clave de cuenta es un secreto completamente incuestionable que solo vive en sus dispositivos .
Lo que esto significa es que, incluso si se capturan todos los datos de nuestro servidor, no hay suficientes datos para lanzar un intento de descifrado. Sin su clave de cuenta, no hay manera de comenzar a adivinar su contraseña maestra.
Simplemente, no queríamos almacenar información que fuera valiosa para cualquier atacante.
Autenticación para preservar el secreto
No es solo que no queremos almacenar información que pueda usarse para lanzar un intento de craqueo, ni siquiera queremos estar en condiciones de adquirir dicha información.
En los inicios de sesión típicos del sitio web, se transmite un secreto de usuario (contraseña) al servidor. Incluso si el servidor no almacena la contraseña (sino solo un hash de contraseña), el servidor tiene la oportunidad en ese momento de aprender la contraseña.
Los mejores sistemas tendrán algún hash de contraseña del secreto realizado por el cliente antes de transmitir, y luego el servidor lo cifrará más antes de almacenarlo. De esta manera, el servidor no tendría la oportunidad de robar la contraseña directamente. Pero el hash que se envían podría usarse para un intento de descifrado de contraseña. Entonces, si bien esto es mejor que el sistema típico, no es suficiente.
Utilizamos un intercambio de clave autenticada por contraseña (PAKE) que significa que no se transmite ningún secreto durante el inicio de sesión . Ni siquiera un hash de secreto. La información que obtenemos durante una sesión de inicio de sesión no nos da nada que podamos usar para tratar de adivinar su Contraseña maestra o Clave de cuenta. El PAKE particular que utilizamos es el protocolo de contraseña remota segura (SRP).
Por lo tanto, no solo no almacenamos nada que pueda utilizarse para aprender sus secretos, sino que incluso hemos configurado las cosas para que sea difícil obtener dicha información.
Aprende más
- 1 seguridad de contraseña
- 1 Privacidad de contraseña
- Sobre la clave de cuenta
- 1 Libro blanco sobre diseño de seguridad de contraseña [PDF]