Solución segura y aceptable para que los usuarios inicien sesión solo con un breve código único (sin nombre de usuario)

Tengo un enfoque similar para algunos servicios web en los que he trabajado, este es efectivamente una autorización basada en token ...

Para mantener esto más seguro aún manejaría todos los tokens de autenticación de la misma manera que las contraseñas.

También es posible que tenga que recordar que si un usuario puede cambiar su token, es posible que puedan crear una colisión con otro token de usuario.

En última instancia, usted será quien tendrá que tomar la decisión sobre qué sistema es lo suficientemente seguro para el contexto, ya que se basará en su modelo de amenaza, pero sin duda podemos proporcionarle información para ayudarlo a tomar esa decisión. .

Por lo tanto, algunos puntos:

1. El método de generación debe ser un dado. Del conjunto de entradas a su disposición, (ya sean caracteres alfanuméricos, una lista de palabras o cualquier otro conjunto de componentes cuyo subconjunto aleatorio será el código), cada elemento debe seleccionarse mediante un psuedo- seguro criptográficamente seguro. generador de números aleatorios. Entonces, eso resuelve el problema de cómo generar los códigos, y deja solo el problema de en qué deben consistir los códigos.

2. Para los elementos seleccionados al azar, la entropía, que determina el nivel relativo de seguridad, se basa en la cantidad de elementos potenciales que está eligiendo y en la cantidad de estos resultados que se encadenan. Por lo tanto, para un código de 6 caracteres, usar las 26 letras mayúsculas y 10 dígitos le dará un poco más de 2 mil millones de códigos posibles (36 ^ 6 o 36 * 36 * 36 * 36 * 36 * 36) para ~ 31 bits de entropía . (36 ^ 6 es aproximadamente igual a 2 ^ 31) Ahora, si estuviéramos tratando de proteger los hashes de contraseñas contra ataques de fuerza bruta sin conexión, esto no sería suficiente para estar seguro. Sin embargo, en su caso, si es como suena, y en realidad no están protegiendo nada, sino sirviendo más para identificar a los usuarios en el primer acceso, luego se combinan con medidas de seguridad adicionales razonables, como los intentos de acceso con limitación de velocidad y la base de datos y el acceso a la base de datos. adecuadamente, puede ser perfectamente adecuado.

3. Sin embargo, si tuviera que usar la lista de Diceware de 7,776 palabras y elegir tres palabras al azar de la lista, la cantidad de códigos potenciales se dispararía a más de 480 mil millones, (7776 ^ 3 o 7776 * 7776 * 7776) que le da más de 38 bits de entropía. (7776 ^ 3 está entre 2 ^ 38 y 2 ^ 39) Todavía no es bueno para la contraseña de un usuario, pero probablemente es lo suficientemente bueno para un código predeterminado. Además, AOL solía usar este sistema para contraseñas predeterminadas durante años, y parecía funcionar lo suficientemente bien para ellas. (¡Y solo usaron dos palabras!)

4. Si desea usar su construcción de [adjetivo] [nombre], entonces deberá averiguar qué tan seguro se basará en la lista de palabras que usa. Para dos palabras, debe multiplicar el número de palabras en la lista de adjetivos por el número de palabras en la lista de nombres para obtener el número de códigos aleatorios potenciales. Un número más grande significa más seguridad. Entonces, si tiene 2000 adjetivos y 4000 nombres, su nivel de seguridad sería 2000 * 4000. Si agregó un segundo adjetivo, 2000 * 2000 * 4000.

Entonces, ahora que sabe cómo medir la intensidad relativa de los códigos generados utilizando diferentes tipos de componentes de entrada, puede tomar una decisión más informada sobre cuál le dará el margen de seguridad que necesita, y luego hay una Algunas otras cosas en las que pensar para el sistema en su conjunto.

1. Como se mencionó anteriormente, los intentos de uso del código de límite de velocidad. Para un sistema de nicho con una base de usuarios pequeña, no hay ninguna razón por la que deba permitir que el sistema procese cientos o miles de intentos de acceso a códigos por segundo. Lo único que causaría esos volúmenes de tráfico sería un ataque de fuerza bruta en línea.

2. Protege tu base de datos. Si tiene vulnerabilidades de inyección SQL en su sitio web, no importa lo buenos que sean sus códigos ... El atacante simplemente los eliminará de la base de datos y los usará a su gusto.

3. Deseche los códigos usados. Dado que solo se utilizan para el acceso inicial al sistema, es de suponer que los usuarios pueden elegir su propia contraseña en ese momento, y el código se vuelve redundante. No deben dejarse en el sistema en un estado en el que puedan reutilizarse después de ese punto para acceder a la cuenta del usuario.

Por lo que ha dicho, parece que el nivel de riesgo aquí es relativamente bajo, por lo que no sé si estaría demasiado preocupado, independientemente de lo que elija. Es de esperar que la orientación anterior lo ayude a sentirse más cómodo con su decisión, y con mayor capacidad para justificar que la decisión que termina tomando es, de hecho, suficientemente segura para el sistema en cuestión.

Tienes varias opciones para códigos como este. Supongo que su idea es utilizar el código como inicio de sesión principal del usuario, y no habría una contraseña por separado. Tiene varias partes de la pregunta, comenzaré con "¿es seguro?"

Respuesta corta, probablemente no sea suficiente. Y no es solo por el contexto de la invitación solamente y por ningún motivo. Siempre hay un motivo, incluso si es solo "para el lulz". El hecho de que el sitio no esté indexado y sea solo de invitación, no significa que algunos blackhat no lo encuentren y quieran jugar. Es posible que no sepan que no tiene información potencialmente valiosa más allá del inicio de sesión. ¿Qué tan grave será si alguien obtiene una copia de su base de datos? ¿Qué tanto problema si alguien roba el código?

5 caracteres pueden ser suficientes para un código de invitación, pero como inicio de sesión es irrazonablemente corto, incluso si hay un número muy bajo de usuarios. Con el tamaño de su código, tiene entre 30 y 60 millones de combinaciones dependiendo del algoritmo de generación y si está limitando los caracteres para evitar confusiones "O vs 0". El código siempre se puede dividir en secciones para que sea más fácil de escribir, digamos A1C-B2X-YP3. 9 caracteres serán al menos un trillón de combinaciones.

En términos de generación de códigos, uno es más corto pero de apariencia aleatoria, el otro es más largo y natural. Elegir un código de lenguaje natural significa que el usuario tiene que escribir más información, y también puede limitar la cantidad de combinaciones si se les ordena que parezcan naturales como una oración. ¿Cómo lidiar con un error tipográfico? ¿Qué pasa si un error tipográfico genera un inicio de sesión válido? Llamar a la opción del lenguaje natural una "frase de contraseña" puede mejorar las cosas para el usuario, ya que la percepción de lo que es puede influir en la capacidad de recordarla y no sentirse intimidada por ella. El otro problema con un código de lenguaje natural es que a un usuario no le gusten algunas de las palabras, o su combinación, puede resultar ofensivo, desagradable o tener mala memoria. A algunas personas realmente no les gusta la palabra "húmedo", por ejemplo.

Como usuario, preferiría un código más codicioso. Podría haber una verificación del dígito de verificación del lado del cliente antes de que el código se use para iniciar sesión. Limitar la cantidad de intentos de inicio de sesión funciona mucho mejor si alguien no puede ingresar un código obviamente inválido. Utilizo un algoritmo para generar códigos como el de una permutación pseudoaleatoria llamada Molibdeno, básicamente un cifrado de bloque personalizado que se asemeja a HIGHT . Internamente es 5 valores de 8 bits, externamente es 8 valores de 5 bits, codificados en 32 caracteres alfanuméricos, con "OIZS" omitido para no confundirse con "0125". Agregue un solo dígito de verificación al final, y son 9 dígitos, lo que se ve bien dividido en 3 grupos de 3. Veo rutinariamente códigos mucho más largos en los correos. Los nuevos códigos se generan al cifrar un contador incremental, por lo que se garantiza que no se repetirán. La generación de códigos al azar requiere una comprobación de todos los códigos en uso para asegurarse de que no haya una colisión. Usar una permutación para generar códigos significa que el acceso debe ser limitado.

También podría forzar un tipo específico de secuencia como un código postal canadiense, que es alternar letras y números. NLN-LNL-NL (N) como 5A9-F4E-0L0 lo limitaría a 4.6 billones de códigos, pero podría ser más fácil de recordar y más fácil de identificar cuando alguien tiene un problema. Asumiría que los usuarios no intentarán recordar, sino que lo mantendrán escrito en algún lugar.

Si un código se usa como una invitación, los códigos cortos están bien, siempre y cuando estén limitados y sean de un solo uso. Supongo que los usuarios no tendrán contraseñas, y solo su ID de usuario. En ese caso, podría considerar un código de invitación como una adición al ID de usuario, que solo se utiliza cuando alguien tiene que llamar para solicitar asistencia como autenticador adicional. De esta manera, utilizarían el código de invitación para obtener su código de usuario cuando se registran, luego el código de invitación se desactiva, pero se almacena con la cuenta. Solo se enviará el código de invitación.

Si no es víctima de un ataque dirigido contra su sistema y sigue las mejores prácticas para proteger el sitio y la base de datos, probablemente estará bien. Hay muchas formas de almacenar y procesar los datos de inicio de sesión, que probablemente están fuera del alcance de su pregunta, que pueden afectar la seguridad del sistema. Auditar la generación y búsqueda de códigos por parte del personal de soporte es una buena idea. He hecho algunas suposiciones aquí debido a la información limitada con respecto a la base de usuarios y al sitio, espero que esta respuesta aún sea relevante.