¿Cómo algunos sitios (por ejemplo, bancos en línea) solo piden caracteres específicos de una contraseña sin almacenarlos como texto sin formato?

Aunque no sé explícitamente cómo los bancos manejan este requisito, un proceso alternativo al que @rakhi menciona sería usar un HSM y cifrado reversible.

La idea es que la contraseña completa se almacene en la base de datos cifrada mediante un cifrado simétrico (por ejemplo, AES). Luego, cuando los caracteres de la contraseña se pasan a la aplicación, se introducen en el HSM junto con la contraseña cifrada.

El HSM podría descifrar la contraseña y confirmar que los 3 caracteres son los esperados, devolviendo una respuesta de aprobación / falla a la aplicación. Por lo tanto, en ningún momento la contraseña se mantiene en blanco (excepto en el HSM que se considera seguro).

Esto se vincularía con la forma en que las redes de cajeros automáticos (p. ej., cifrado simétrico y HSM) pueden manejar el cifrado de PIN

Cada vez que se encuentre con un caso en el que se necesite saber algo sobre su contraseña que no sea el hash de la contraseña completa, puede suponer que la contraseña no está hash. Si bien se mencionó el PCI-DSS, no hay ninguna regulación de la que yo sepa que se aplique a los bancos que cifran la información de contraseña de hash. PCI-DSS no cubre la información de su cuenta bancaria, incluido el inicio de sesión con su PIN o alguna variación de este.

Si están siendo buenos, la contraseña se almacena mediante cifrado. Si no son tan buenos, de hecho podrían almacenarse en texto plano.

Admito que me gusta más la compensación aquí. Toda la base de datos de contraseñas puede estar expuesta a un mayor riesgo de ataque si está comprometida, pero contrarrestaría que la seguridad en los bancos debería en el extremo superior. Si se sospechara un compromiso con la base de datos, todo tendría que cambiarse, ya sea con hash o cifrado. Cualquier instancia Con este método en particular, se necesita mucho más tiempo y un mayor grado de complejidad para que un atacante obtenga suficiente información útil para realizar un ataque con un registrador de teclas.

Algo relacionado tangencialmente: enlace

El esquema de NatWest me parece de dudoso valor. En el esquema de NatWest, un ataque de phishing probablemente puede robar su PIN completo y la totalidad o la mayoría de su contraseña. Así es como funcionaría el ataque de phishing.

1. El sitio de phishing presentaría una pantalla de inicio de sesión falsa, solicitando 3 dígitos del PIN y 3 caracteres de la contraseña.

2. El usuario escribiría su respuesta en.

3. El sitio de phishing ahora presentará una respuesta que indica que la entrada fue incorrecta y volverá a preguntar al usuario.

4. Probablemente, muchos usuarios asuman que ingresaron algo incorrecto e intentan nuevamente.

Si el phisher es inteligente, el segundo indicador del sitio de phishing solicitará un conjunto diferente de dígitos y caracteres. Si el usuario intenta una segunda vez, entonces el sitio de phishing puede aprender los 4 dígitos del PIN y los 6 caracteres de la contraseña del usuario. (Tenga en cuenta que NatWest requiere que los usuarios elijan una contraseña que contenga de 6 a 8 caracteres, por lo que se garantiza que 6 caracteres de la contraseña sean todos o casi todos). En ese momento, se acabó el juego.

En consecuencia, no me queda claro que el esquema de NatWest te compre algo.

En pregunta similar , un comentario de @captaincomic se ha vinculado a este artículo: Partial Passwords - ¿Cómo? (De Archive.org) Explica cómo permitir esta funcionalidad sin almacenar la contraseña en una forma recuperable o hashing cada carácter por separado, utilizando el esquema de intercambio secreto de Shamir.

Sólo está relacionado tangencialmente, pero David Aspinall (Universidad de Edimburgo) y Mike Just (Glasgow Caledonian University) publicaron un documento sobre contraseñas parciales en 2013: " Give Me Letters 2, 3 and 6! ": Implementaciones de contraseña parcial & Ataques .

Su artículo analiza los ataques en línea para los cuales el mecanismo de almacenamiento backend es irrelevante, pero hace un comentario pasajero que es pertinente a su pregunta:

  

Para admitir el protocolo parcial, la implementación deberá:   almacenar texto sin formato para la contraseña, o diseñar un mecanismo para   realizar comprobaciones unidireccionales en todas las combinaciones que puedan consultarse   (que puede ser un número grande para contraseñas largas). No investigamos   este modo de ataque aquí.

Lo que están haciendo es agrupar cada carácter y guardar eso o almacenar la contraseña en un dispositivo seguro, por ejemplo. HSM.

No es un mal enfoque; el banco solicita al usuario que ingrese un número de caracteres (por ejemplo, HSBC es 3 desde posiciones aleatorias). Significa que si un troyano, un registrador de claves o un sitio de phishing capturaron esos 3 caracteres, no tienen la contraseña completa.

También le permite al banco usar la contraseña parcial para autenticar a los usuarios por teléfono, etc. sin tener que confiar en preguntas secretas o una contraseña diferente, de nuevo sin que la persona del centro de llamadas sepa la contraseña completa

Algunos problemas, probablemente es por eso que no se usa más ampliamente:

• El principal es que no desea almacenar la contraseña de forma clara (de hecho, las regulaciones como PCI-DSS lo prohíben). Así que el enfoque es crear un hash de una sola vía de la contraseña y almacenarlo. Cuando el usuario ingresa la contraseña, esta se revisa y se compara con el hash almacenado, si coinciden, el usuario se autentica. Con una contraseña parcial, tiene que almacenar la contraseña con un cifrado reversible que no es la mejor práctica o almacenar una gran cantidad de hashes, por ejemplo. para HSBC con un cumpleaños más cada carácter de la contraseña requiere un hash separado. También debe imponer una longitud máxima de contraseña para poder asignar los campos en la base de datos para almacenar todos los hashes (aunque probablemente haya una base de datos más inteligente y tecnologías de aplicación que podrían evitar esto)

• Alienta a los usuarios a seleccionar contraseñas débiles, por ejemplo. Si tengo una contraseña compleja de 8 caracteres: tpEz% e2S. Tratar de recordar cuál es el segundo, cuarto y quinto carácter es difícil, lo que alienta a los usuarios a seleccionar una palabra simple del diccionario.

• Además, si no hay características de tipo de bloqueo de cuenta, es exponencialmente más fácil de adivinar o fuerza bruta 3 caracteres que 8 caracteres.

• La confianza de que no se conoce la contraseña completa podría estar mal colocada, por ejemplo. si la contraseña es Fulham y sabe que F, l, h, tal vez pueda hacer una estimación correcta de la contraseña completa

• Un sitio de phishing que simplemente solicitó el 1º, 3º, 5º y luego dijo que la contraseña es incorrecta y que se cambió para solicitar el 2º, 4º y 6º también podría obtener la contraseña completa, ya que el usuario probablemente la ingresaría antes de que lo pensara dos veces / p>

• Desde la perspectiva de la conveniencia del usuario, significa que no pueden usar la contraseña de recordar del navegador o un administrador de contraseñas como Lastpass o 1Password

La mayoría de los bancos se están alejando de confiar en un nombre de usuario y contraseña, por ejemplo. HSBC ofrece un token RSA para clientes comerciales, Barclays tiene lector de tarjetas inteligentes EMV, casi todos utilizan tecnología de detección como la autenticación adaptativa RSA para establecer una línea de base de navegador, ubicación, perfil de uso, velocidad, etc. para autenticación pasiva y detección de uso no autorizado.