Para admitir "contraseñas parciales", el banco debe almacenar necesariamente la contraseña de texto sin formato, o al menos algunos valores que permitan una rápida reconstrucción de la contraseña completa. Se ve fácilmente de la siguiente manera: cuando el banco solicita, digamos, las letras tercera, cuarta y octava de la contraseña, entonces hay menos de un millón de posibilidades (suponiendo que las "letras" sean caracteres imprimibles). Sin embargo, el banco puede decidir de alguna manera si las tres cartas proporcionadas son las correctas o no. Por lo tanto, lo que sea que el banco almacene es suficiente para ejecutar un ataque de fuerza bruta en las letras 3, 4 y 8, y ese ataque tendrá éxito en menos de un millón de intentos.
El banco puede agregar capas de cifrado y hash, y lo que no, esto no cambiará ese hecho en bruto. Siempre que haya soporte para "contraseñas parciales", entonces hay un almacenamiento muy sensible en el lado del servidor. En ese sentido, la compatibilidad con contraseñas parciales disminuye la seguridad, en lugar de aumentarla. (Se puede argumentar que las contraseñas parciales aumentan la seguridad en el lado del cliente: hombro surfistas obtienen solo una vista parcial de la contraseña. Sin embargo, debe tener en cuenta que esto es un compromiso: más seguridad del lado del cliente por menos seguridad del lado del servidor.)
Para admitir la autenticación de contraseña completa, el banco debe almacenar algo que sea suficiente para verificar una contraseña completa. Se aplica el mismo razonamiento anterior, pero para un ataque de fuerza bruta en la contraseña completa, no en una contraseña parcial. Si un banco admite las autenticaciones de "contraseñas parciales" y de "contraseña completa", probablemente almacene una de las siguientes opciones:
-
La contraseña completa en un formato "recuperable" (texto sin formato o encriptado con una clave que el servidor conoce: que el cifrado es la protección contra atacantes informales en el lado del banco, por ejemplo, pasantes mal pagados).
-
Un hash de la contraseña completa y los hashes para todos los subconjuntos de contraseñas que el banco puede solicitar al usuario que se conecta.
La segunda posibilidad requiere mucha más complejidad de almacenamiento e implementación en el lado del banco, por lo que la considero improbable. Los desarrolladores de aplicaciones bancarias no son menos perezosos que sus compañeros humanos.
Tome nota de que su contraseña es no su activo más confidencial confiado al banco. El banco retiene su dinero . Y el dinero es lo que buscan los atacantes. Si un atacante secuestra completamente el servidor de autenticación, no se limitará a capturar contraseñas cifradas o con hash; Inmediatamente falsificará alguna autenticación exitosa y activará transferencias. ¿Quién necesita una llave para una puerta cuando ya está adentro?
Las discusiones sobre las contraseñas cifradas o con hash son relevantes para las violaciones parciales , por ejemplo. cuando el atacante encuentra una cinta de copia de seguridad para una base de datos u obtiene una vista de solo lectura a través de algún ataque de inyección de SQL. En ese tipo de escenario, lo que un atacante puede hacer depende en gran medida de los detalles sutiles de cómo se implementan las cosas en el servidor, por lo que es difícil hablar en general.