Si la autenticación se produce al pedirle al usuario los caracteres en ciertas posiciones en la contraseña (como: dar el tercer y el séptimo carácter en la contraseña), ¿esto implica que las contraseñas se almacenan sin daños? ¿O existen técnicas seguras de hashing donde es posible verificar el hash de un subconjunto de la contraseña con el hash de toda la contraseña?
Si puede verificar la contraseña por carácter, se reduce significativamente la fuerza efectiva de la contraseña. En lugar de ser exponencialmente más fuerte para cada personaje, solo sería incrementalmente más fuerte.
Por ejemplo, digamos que tengo una contraseña de cuatro caracteres que es "ABCD". Si tengo que saber la contraseña completa para hacerlo bien, las posibles permutaciones (por ejemplo, solo superior, inferior y numérica para los argumentos) son 62 ^ 4, o 14.8M combinaciones posibles. Si, por otro lado, puedo determinar el éxito de cada personaje por sí mismo, puedo encontrar la contraseña en 62 * 4 combinaciones, o 248 operaciones usando fuerza bruta.
Por lo tanto, si bien es posible o no hacer hash de una contraseña de esta manera, hacerlo eliminaría cualquier seguridad al hacerlo.
Es posible que el servicio no solo haya calculado el hash de la contraseña completa cuando se creó, sino que también se incluyó el tercer y el séptimo carácter (o posiblemente todos los caracteres) individualmente. De esa manera, técnicamente no estarían almacenando los caracteres o la contraseña completa en texto sin formato. Sin embargo, esta sería una idea terrible. Un hash de un solo carácter no es esencialmente mejor que el texto simple, ya que solo hay quizás 62 posibles hashes de un solo carácter por sal (si se usa una sal).
De cualquier manera, si el servicio tiene la capacidad de reconocer parte de la contraseña en lugar de solo la contraseña completa, es una mala noticia.
Cualquier autenticación que solicite al usuario detalles sobre la contraseña indica que la contraseña de texto simple está disponible para el sistema. Esto significa que no están dañados, pero aún pueden estar encriptados y protegidos por otros medios.
No hay técnicas para verificar el subconjunto de una contraseña con hash contra toda la contraseña con hash. Este es en realidad uno de los objetivos de una función hash, ya que protege contra la adivinación de una contraseña carácter por carácter.
Como ya se ha indicado en las respuestas anteriores, no se conoce ninguna técnica para realizar un hash parcial de una contraseña y verificar la cadena. La naturaleza de las funciones hash unidireccionales hace que sea imposible verificar si una contraseña es similar a otra, solo que las contraseñas son idénticas. Por lo tanto, implicaría que el banco ha almacenado las contraseñas utilizando cifrado bidireccional, mediante el craqueo de las subcadenas o (¡el horror!) Como texto simple.
Esta técnica en realidad tiene varios beneficios e inconvenientes, contrariamente a las opiniones actuales de que esta técnica no tiene factores de redención.
El compromiso de las contraseñas bancarias se puede llevar a cabo de dos maneras: mediante la piratería de los servidores bancarios, lo que resulta en una pérdida de hash, o mediante el compromiso de la contraseña en el extremo del usuario (registradores de teclas, troyanos, navegación simple, ataques MITM en SSH), etc.
El almacenamiento de las contraseñas de manera que se puedan recuperar las subcadenas permite que un pirata informático que haya accedido a la base de datos del banco obtenga fácilmente las contraseñas de texto sin formato, incluso si son extremadamente fuertes. Si el banco utilizara el cifrado bidireccional, es casi seguro que un pirata informático que haya accedido a la base de datos cifrada podría obtener las claves. Si en lugar de eso, hayan hecho una selección de subcadenas, se obtendría un caso similar a los hashes débiles NTLM que harían Es fácil recuperar las contraseñas de texto plano. El espacio de hash muy pequeño de 3-5 caracteres (suponiendo que se usó un hash) haría que los intentos de inversión fueran triviales, incluso si se usara una sal.
Sin embargo, esto debe ser equilibrado contra riesgos alternativos. Un potencial pirata informático bancario que haya obtenido acceso solo a la computadora de la víctima (y posiblemente también a su token de autenticación de 2 factores) no podrá acceder a la cuenta bancaria de la víctima, ya que se requeriría un subconjunto diferente de caracteres de la contraseña.
Dado que el último caso de compromiso de seguridad de cuentas bancarias es mucho más probable, tiene sentido hasta cierto punto para que los bancos implementen tales sistemas de hash.
Parece que la contraseña parcial no necesita ser almacenada de manera equivalente a texto simple. Este esquema, basado en el esquema de intercambio secreto de Shamir podría ser útil: enlace
A. Parámetros globales
Al principio, alguien tiene que definir los parámetros globales de la sistema. Bueno, en realidad solo hay una: cuántas letras van a usar los usuarios Hay que seleccionar. Llamemos al parámetro N. La longitud máxima de La contraseña (L) es importante solo desde el punto de vista de la base de datos. Tendrá que almacenar un número largo de 32b para cada personaje.
B. añadiendo nuevo usuario
- El usuario elige su contraseña P. Se compone de las letras p1, p2, p3, ... pk.
- El sistema generará al menos una clave secreta larga de 32 bits, K, única para cada usuario. 32 bits son suficientes si N es 3, para N mayor (la cantidad de letras que los usuarios deben seleccionar correctamente cada vez) es posible que desee aumentar la longitud de K.
- El sistema también generará N-1 números aleatorios de 32 bits R1, R2, ... R (N-1)
- El siguiente paso es un cálculo de k puntos (siendo k la longitud de la contraseña) en un polinomio: y = K + R1 * x + R2 * x ^ 2 + ... + R (N-1) * x ^ (N-1), para x = 1, 2, ... k. Denotemos los resultados como y1, y2, ..., y (N-1).
- Los valores s1 = (y1-p1), s2 = (y2-p2), ... sk = (yk-pk) se almacenan en la base de datos. Cada número lleva 32 bits. También se necesitará almacenar K, o el hash de K.
C. Autenticación
La siguiente parte del sistema es la autenticación del usuario, que es muy Sencillo y rápido.
- El sistema selecciona N posiciones en la contraseña: i1, i2, ... iN.
- Un usuario selecciona N letras de su contraseña en posiciones específicas para que tengamos pares (p'1, i1), (p'2, i2), ..., (p'N, iN).
- El sistema recupera los valores yi para los índices que seleccioné en el paso 1, simplemente agregando valores almacenados (ver el paso 5 anterior) a los valores p'i ingresado por los usuarios.
- Ahora tenemos que resolver la ecuación polinomial para obtener K '. La ecuación para eso se ve horriblemente pero es rápida de calcular y puede incluso ser parcialmente precalculado, ya que utiliza índices (posiciones de letras): K '= \ sum_i [yi * [(\ PI_j (j)) / (\ PI_j (i-j))]], donde i y j se ejecutan sobre i1, i2, ..., iN (paso 1) y j omite el real seleccionado i. Ejemplo: digamos que el usuario seleccionó las letras 2, 3 y 4, la solución será: K '= y2 * (3 * 4 / [(2-3) (2-4)]) + y3 ( 2 * 4 / [(3-2) (3-4)]) + y4 (2 * 3 / [(4-2) * (4-3)])
- El último paso es comparar K y K '. Si son iguales, el usuario ingresó los valores correctos y está conectado.
Una nota aquí: el secreto no es K, sino que se reconstruye yi cuando el usuario ingresa sus letras.
(No soy un experto en seguridad y no sé si este esquema tiene sentido)
Si siempre usan el tercer y el séptimo carácter para esto, es posible que solo guarden los hases de la contraseña y este extracto. Esencialmente, esto dividiría su contraseña de longitud completa abcdefghijklm en dos contraseñas más cortas cg y abdefhijklm . De estos, la contraseña de dos caracteres ofrece prácticamente ninguna seguridad. Además, la contraseña restante no solo se ve reducida por dos caracteres, también es susceptible de ataques "cuna": a menos que la contraseña original sea completamente aleatoria, los caracteres que se adivinan fácilmente dan una buena pista de lo que somos. buscando (por ejemplo, entre todas las contraseñas en uso con el séptimo carácter 2 apuesto a que existe una proporción significativa que tiene una longitud exactamente 10 y termina en algo entre 2000 y 2015 ).
En cualquier caso, si hubieran considerado las implicaciones de seguridad lo suficiente como para almacenar los "extractos" de la contraseña de manera segura, deberían haber notado que el extracto es un gran riesgo. Esto sugiere que no se hicieron tales consideraciones, lo que nuevamente sugiere que almacenen la contraseña en texto claro (también conocido como la navaja de afeitar de Occam).