Inicie sesión con un hash. ¿Es esto lo suficientemente seguro?

Navega tus respuestas
3

Necesito proporcionar a los clientes de la tienda una herramienta para verificar el estado de sus pedidos de reparación.
Los clientes no tienen un usuario o contraseña. Son solo un registro en la base de datos. Sin embargo, tengo que darles una forma de iniciar sesión en la página web y verificar su estado (listo o no). Forzar entonces a registrarse no es una opción.

Vine con esta idea:

  • Se le solicita al usuario su dirección de correo electrónico
  • El sistema verifica si este correo electrónico está registrado en la base de datos, genera un hash y envía un url especial por correo electrónico con el hash.
  • El usuario verifica el correo electrónico y va a esta dirección
  • Cuando el sistema recibe una solicitud de verificación de dirección especial si el hash está en la base de datos y recupera el id_usuario
  • Si está presente, ¡voilá! Hola, John Doe Su pedido # 3454364 está listo para ser recogido

El algoritmo de generación de hash sería. 

SELECT clients set hash = SUBSTRING(PASSWORD(UUID()), 2);

El hash / contraseña está salted y Bcrypt (ed) en el servidor.
Podría agregar un tiempo de espera (hash válido por 1 día o algo así)

¿Hay algo horriblemente mal con esta idea?

ACTUALIZACIÓN: Se corrigió la redacción para que sea menos confuso.

¿Qué factor de trabajo debo usar para Bcrypt? Parece que la idea general es aumentar el número hasta que demore ~ 1 segundo.

Me gusta la salida de PASSWORD de MySQL para la generación de hash porque es muy amigable con url. Pero esa es realmente la única razón. ¿Alguna otra sugerencia?

    
pregunta The Disintegrator 18.05.2013 - 09:32
fuente

2 respuestas

3

La idea en sí está bien, sus usuarios están realizando acciones no críticas utilizando una URL especial. Sin embargo, hay dos cosas que podrían ir mal aquí:

  • Su identificador es SUBSTRING(PASSWORD(UUID()), 2) , el problema es que UUID() no es muy confiable para generar identificadores impredecibles e indiscutibles.
  

ADVERTENCIA: Aunque los valores UUID () están destinados a ser únicos, no son   Necesariamente impensable o impredecible. Si la imprevisibilidad es   requerido, los valores UUID deben generarse de otra manera.

Es mucho mejor generar identificadores aleatorios basados en la salida de /dev/urandom

  • Al no utilizar SSL (HTTPS), el identificador único se transmitirá en texto sin formato (y el estado del pedido) y, por lo tanto, estará expuesto a cualquier persona que detecte la conexión de su cliente.

Pero en general, digo que es una solución bastante buena para su propósito.

    
respondido por el Adi 18.05.2013 - 09:48
fuente
4

Para el nivel de seguridad que su servicio suena como requiere, yo diría que esto suena como una solución razonable.

Los riesgos son que alguien intercepte un enlace y obtenga acceso a la información de los clientes, por lo que debe asegurarse de que el acceso a la página de estado esté cifrado mediante SSL.

Para el tiempo de espera, puede optar por el enfoque que tiene (basado en el tiempo) que parece razonable según las circunstancias, o puede configurar cada hash para que se use solo una vez (es decir, el hash debe ser reevaluado). creado cada vez que el cliente lo usa)

Una alternativa que he visto utilizada para este tipo de sistema que es algo menos segura pero más fácil de usar para los clientes, es solicitar información sobre el pedido (por ejemplo, ID de pedido, apellido del cliente, código postal del cliente). Esto elimina el paso del correo electrónico, pero es susceptible a un ataque de fuerza bruta.

La seguridad de su uso depende en gran medida de la confidencialidad de la información y de la molestia que puedan tener los clientes si alguien más tiene acceso a ella.

    
respondido por el Rоry McCune 18.05.2013 - 09:48
fuente

Lea otras preguntas en las etiquetas

¿Qué longitud de clave AES elegir para OpenVPN? Autorizar el uso de aplicaciones de un almacén público sin servicio de back-end