Usando una Cryptovariable con una API diseñada para contraseñas generadas por humanos

2

Estoy trabajando con un proveedor que proporciona una API con un método de registro de usuario claramente diseñado para contraseñas generadas por humanos. Sin embargo, estamos llamando a la API sin conexión de servidor a servidor y nos estamos registrando con la API en nombre de nuestro usuario.

Me siento relativamente cómodo con la idea de generar nuestra propia criptovariable, en lugar de reutilizar la contraseña del usuario o forzar al usuario a generar su propia segunda contraseña para la API. De cualquier manera, debido al diseño de la API, nos veremos obligados a almacenar la contraseña / criptovariable, que además se cifrará tanto en reposo como en el cable.

La única queja que tengo es que la API (de nuevo, aparentemente diseñada para contraseñas generadas por humanos), tiene algunas restricciones en el formato de contraseña que disminuyen la entropía cuando se utiliza un generador de números aleatorios criptográficos para generar la "contraseña" (con mayor precisión una criptovariable). Puedo hacer los cálculos en todos ellos excepto uno (y hacer que el código sea correcto también es bastante razonable).

La regla de "contraseña" más criptovariable y hostil es que no puede haber secuencias repetidas de caracteres en la contraseña. En otras palabras (y sin tener en cuenta las otras reglas de contraseña que impone la API), 'ab' y 'ba' están bien, pero 'aa' y 'bb' no. Para ese caso simple específico, suponiendo una longitud fija de dos y solo los dos símbolos 'a' y 'b', puedo ver que la restricción reduce exactamente la entropía, y también puedo ver que es mejor a medida que aumenta la longitud. En mi caso, simplemente duplicaría la duración y lo llamaría un día, excepto que también hay una restricción de longitud máxima de contraseña (¡doh!).

Basta de antecedentes: mi pregunta concisa es:

¿Cuál es la entropía de una criptovariable de 48 símbolos de longitud fija, generada aleatoriamente, que consta de 64 símbolos (AZ, az, 0-9, + y /), donde cualquier combinación con cualquier secuencia repetida de símbolos? ¿Están excluidos?

Como cuestión de edificación personal, también me gustaría saber no solo cuál es la respuesta en este caso específico, sino que también me gustaría entender cómo determinar la entropía para las condiciones "no repetitivas" para varias longitudes. y conjuntos de símbolos. Parece que esto podría ser incluso un ejercicio en un libro de texto de criptografía, y me encantaría una referencia.

Y, ahora que estoy listo para admitir que ya he pasado MUCHO más tiempo en esto de lo que esperaba, también me pregunto:

¿Estoy siendo paranoico?

Específicamente, dado que las contraseñas que siguen estas reglas son teóricamente "lo suficientemente seguras" de los ataques de fuerza bruta que la entropía restante es "suficiente", puedo, en buena conciencia, simplemente confiar en que la API es ¿Bastante "suficientemente bueno", llámalo un día y vete a tomar una cerveza?

- Tim

p.s. También debo tener en cuenta que estoy abierto a otras soluciones fuera de la caja para el problema en cuestión también, pero ya he descartado almacenar la contraseña generada por el hombre en forma local y pedirle al usuario de manera interactiva cuando necesitamos pasarla. a través de la API.

Reutilizar la contraseña del usuario nos obligaría a almacenar localmente la contraseña personal real del usuario, en lugar de utilizar la práctica estándar de la industria, mucho más apropiada, de almacenar un hash de la contraseña de una sola vía, por lo que definitivamente no queremos haz eso.

Forzar la interacción del usuario para generar una segunda contraseña es una mala experiencia para el usuario en general, y prácticamente garantiza un alto grado de reutilización de la contraseña por parte de muchos usuarios, por lo que tampoco queremos hacerlo. Además, y de manera más crítica, estamos accediendo a la API en su mayoría fuera de línea. A pesar de la acidez estomacal, este problema en particular me está dando, el uso sin conexión es totalmente compatible con la API según la documentación. En cualquier caso, dado que estamos accediendo a la API sin conexión, no tenemos la oportunidad de solicitar al usuario que ingrese la contraseña, por lo que tampoco podemos hacerlo.

    
pregunta Timothy Johns 27.02.2015 - 21:16
fuente

1 respuesta

3

La entropía de computación para una contraseña elegida al azar se puede dividir en una regla simple que se puede usar en prácticamente todos los casos, con algunas advertencias. Es el log2 () del espacio del conjunto de caracteres de la contraseña elevado a la potencia de la longitud de la contraseña. Entonces, con una contraseña completamente aleatoria donde todos los caracteres son independientes, este es un cálculo fácil. E.G., para una contraseña de 8 caracteres de longitud y compuesta solo de letras mayúsculas en inglés, es: log2(26^8) o ~ 37.6 bits de entropía. Otra forma un poco más detallada de expresar esto es: log2(26*26*26*26*26*26*26*26) . Si tuviéramos que agregar una restricción a nuestra contraseña, tal vez debe ser cuatro caracteres en mayúscula y luego dos dígitos, una contraseña generada aleatoriamente tendrá log2(26*26*26*26*10*10) bits de entropía. (~ 25.4 bits)

Entonces, en un caso más complejo como el suyo, debe determinar cuántos caracteres están disponibles para cada posición sucesiva para determinar el espacio de la contraseña y, por lo tanto, la entropía. La condición que prohíbe la repetición significa que no puede conocer de antemano la entropía de una contraseña específica, porque el conjunto de caracteres para elegir estará limitado por los caracteres ya elegidos ... Por lo tanto, solo puede calcular la entropía mínima si los caracteres se eligen al azar como máximo. restringir el espacio de caracteres para los caracteres posteriores. En realidad no quiero elaborar este cálculo específico, pero en general, para evitar cualquier secuencia repetitiva, solo necesita limitar el espacio de caracteres por el último carácter elegido (para que no obtenga bb) y si hay algún incidente anterior de El personaje anterior, los personajes que siguen esos incidentes. (Por lo tanto, si para este punto la contraseña es abcdbeb, deberá excluir b, c y e del espacio de caracteres para el siguiente carácter). Como puede ver, esto significa que a medida que la contraseña crece, el carácter disponible el espacio no solo se reducirá, sino que su tamaño solo se conocerá después de que se hayan examinado los caracteres seleccionados previamente.

Entonces, el método súper simple para determinar la entropía mínima con un margen de error máximo que mencioné en el comentario es simplemente excluir cada carácter a medida que se usa. Sin posibilidad de que un personaje sea usado dos veces, no hay posibilidad de repetir una secuencia. Con un espacio de caracteres que comienza con 64 caracteres y una contraseña que tiene 48 caracteres de longitud, esto es log2(64*63*62*...*16) , que es una masiva ~ 249.7 bits de entropía. Por lo tanto, ya que sabemos que dadas sus restricciones específicas, la entropía de sus contraseñas será mayor, usted tiene un gran margen de seguridad y no hay posibilidades realistas de un ataque exitoso de fuerza bruta.

Como nota aparte, si no tuviera restricciones y eligiera aleatoriamente 48 contraseñas de caracteres de un conjunto de 64 caracteres, habría tenido 288 bits de entropía.

    
respondido por el Xander 27.02.2015 - 23:48
fuente

Lea otras preguntas en las etiquetas