Autenticación de clave (token de sesión) frente a la autenticación de inicio de sesión / paso predeterminada

Question

Autenticación de clave (token de sesión) frente a la autenticación de inicio de sesión / paso predeterminada

#1 de Sas3 (1 votos)
#2 de Jacco (0 votos)

0

Estoy creando una aplicación web y tengo una idea para crear un sistema de autenticación personalizado, que sería rápido y seguro.

No quiero utilizar la combinación de inicio de sesión (correo electrónico) / contraseña casi "predeterminada".
Quiero generar para todos los usuarios una clave de cadena segura criptográficamente única al azar (por ejemplo, 70 caracteres aleatorios) cuando se inscriban.

Habría solo un campo de entrada para iniciar sesión, donde el usuario tendrá que ingresar esta clave para restaurar su sesión nuevamente.

Lo único que me preocupa es su seguridad.
¿Cuáles son los problemas con los que tengo que lidiar al usar este método de autenticación?

El único problema, sospecho por ahora es la fuerza bruta. Pero por lo que entiendo, si tomo cualquier biblioteca para generar, por ejemplo, tokens de contraseña de recuperación de correo electrónico, la posibilidad de fuerza bruta será pequeña. Además, desde matemáticas (corríjame por favor si me equivoco) la posibilidad de dañar dos campos de 20 caracteres de longitud (como inicio de sesión y contraseña) es igual a un campo de 40 caracteres de longitud (mi clave) si tienen el mismo conjunto de caracteres.

EDIT 1: Agregué ese hecho, esa clave no solo debe ser aleatoria, sino también única, para que sea posible usarla como una identificación. Sin embargo me pregunto si hash, usando, en ex. Bcrypt también sería único. ¿Es posible lograr eso? ¿Será el hash único si la clave es única? ¿Es alto el riesgo de colisión?

authentication brute-force session-management

pregunta Sabine 24.06.2017 - 13:46

fuente

2 respuestas

1

Tal vez me esté perdiendo algo, pero esto todavía se siente como reinventar la rueda. A medida que continúa agregando provisiones para problemas potenciales, siento que convergerá cerca de algo que usamos actualmente.

Pienso en la autenticación como esta:

Al registrarme, declaro que soy X (mi ID de usuario / correo electrónico); y proporciono un secreto (la contraseña Y) que solo usted (el sitio) y yo conozco.
Cuando vuelva a iniciar sesión la próxima vez, te digo que soy X; y para probarlo, te digo el secreto compartido que acordamos cuando me inscribí. Así aceptas que soy la misma X.

En el lenguaje de seguridad, tratamos esto como solo uno de los 3 factores comunes. Podría agregar más factores, pero no puedo ver cómo podríamos reducir el primer factor del par de elementos de datos (X, Y) a un solo elemento de datos.

Sin embargo, en general, es absolutamente esencial proporcionar UX completamente suave a los usuarios, y cualquier intento en esa dirección es loable. Por ejemplo, la forma en que lo hacemos en nuestra aplicación de seguridad del sitio web ActiFend es de

No solicitar el registro (inicio de sesión por primera vez = registro)
Aceptar autenticación federada: use su cuenta de Google / FB / LinkedIn y obtenga la dirección de correo electrónico (solo eso) desde allí. Si Google dice "hey revisé a este usuario y lo estoy aceptando como X", eso es suficiente para nosotros para este propósito.
Para aquellos que desean otra opción, enviamos una OTP basada en correo electrónico, para que no sea necesario almacenar / guardar ninguna contraseña; complejo o no.

No somos los únicos que intentamos nuevas ideas para esto ... por ejemplo, Slack usa "enlaces mágicos" (un término fácil de usar para representar la autenticación de canales alternativos); Twitter y Google aceptan una autenticación de canal alt similar (autentíquese desde otro dispositivo donde ya haya iniciado sesión).

Hay muchas ideas, pero ninguna de ellas ha logrado reducir los datos a uno. Puede ocultar uno de los elementos del usuario (por ejemplo, puede tomar la ID del dispositivo como X; o su dirección IP como X ... cada uno con sus propios problemas), pero creo que no puede evitarlo por completo.

No puedo articular esto mejor ... Espero que esto todavía ayude.

respondido por el Sas3 24.06.2017 - 15:36

fuente

Lea otras preguntas en las etiquetas authentication brute-force session-management

¿Bajo qué condiciones debo volver a firmar una clave PGP que ha sido transferida? ¿Puede un usuario tener un certificado o solo una máquina tiene un certificado?

score 0 · Accepted Answer

La clave secreta sería una contraseña (segura) equivalente. Por lo tanto, necesitaría almacenar un hash de la contraseña (porque no quiere que alguien que ingrese su sistema obtenga todas las claves secretas de las claves secretas de su usuario de una sola vez).

Debido al requisito de hash de la contraseña, necesitarías algún método para identificar con qué contraseña hash necesitas comparar el secreto dado. Normalmente, esto se hace por medio de un identificador público (generalmente el nombre de usuario del usuario).

Entonces, si extiendes tu esquema para usar algún tipo de identificador público (llámalo ID o clave API o lo que sea más apropiado en tu caso de uso exacto), además de su clave segura criptográficamente, tu esquema será mejor (debido a la 'contraseña' más fuerte) que su combinación típica de nombre de usuario y contraseña.

Sin embargo, esto es solo un elemento de una configuración segura: otras cosas incluyen el uso de SSL / TLS, un buen algoritmo de hashing de almacenamiento de contraseñas (por ejemplo, BCrypt), un método seguro para comunicar inicialmente la clave segura criptográficamente a su usuario. etc. etc.