¿Serían demasiado inseguros los múltiples hashes bcrypt expuestos del mismo UUID v4 con sal generada al azar?

Question

¿Serían demasiado inseguros los múltiples hashes bcrypt expuestos del mismo UUID v4 con sal generada al azar?

#1 de Tom Leek (2 votos)
#2 de Jonathan (0 votos)

1

Estoy considerando implementar una verificación de propiedad en los objetos JSON y quiero evitar volver a la base de datos para asegurar la propiedad de dicho objeto / registro (es decir, para evitar que un usuario actualice un objeto / registro que no posee) en su mayoría operaciones de CRUD). Esto ocurriría en el contexto de una aplicación web / api de servicio.

Mi idea es tener un sistema privado del lado del servidor asignado a la "propiedad" del UUID v4 vinculado a cada registro de usuario, de modo que al pasar cualquier objeto JSON propiedad del usuario a la vista, el sistema cifra el UUID privado de la "propiedad" del propietario usando bcrypt con un salt aleatorio y lo asigna al objeto / registro (donde podría persistir junto con el registro para propósitos de almacenamiento en caché, por lo que no es necesario volver a cifrarlo). Además, debo señalar que es posible que los objetos de propiedad se puedan cifrar por separado, cada uno con su propio sal generado aleatoriamente, aunque en realidad son el mismo UUID del usuario (esto es necesario para ayudar a evitar el seguimiento de la propiedad del objeto del usuario en ciertas aplicaciones) casos).

Más tarde, si un usuario intenta actualizar dicho objeto, el servidor tendría que validar su UUID privado contra el hash bcrypt para asegurarse de que tienen los derechos de propiedad para actualizar el registro.

Esto se supone que yo cifraría usando un número apropiado de rondas para el cifrado. Otra suposición que estoy haciendo es que el tiempo de cifrado y verificación superaría cualquier tiempo de verificación de la base de datos. El último supuesto a señalar es que esto es estrictamente un control de seguridad de la aplicación y no haría nada si alguien realmente se apoderara de la base de datos.

Mi idea actual es que, dado que el UUID es aleatorio y su tamaño de cadena grande (junto con un número apropiado de rondas) haría que tener estos hash bcrypt expuestos públicamente no sea un problema tan grande. ¿O es este enfoque simplemente demasiado riesgo / supervisión?

web-application hash encryption bcrypt web-service

pregunta Jordan 11.10.2013 - 20:40

fuente

2 respuestas

0

Otro enfoque es firmar los campos seguros utilizando HMAC.

{"RecordID": "nnn", "Day": "day_since_epoch", "OwnerUserId": "[email protected]", "OwnerUserIdHmac": "{yyy}", ...}

Donde yyy = HMAC ($ RecordID + $ OwnerUserId + $ Day, $ SecretKey [$ Day])

La clave secreta se rota todos los días y puedes descifrarla usando la clave de un día anterior.

respondido por el Jonathan 11.10.2013 - 21:11

fuente

Lea otras preguntas en las etiquetas web-application hash encryption bcrypt web-service

Brute force cracking cracking con una GPU Problemas con los certificados SSL intermedios y el proxy SSL

score 2 · Accepted Answer

No necesitas bcrypt aquí.

Bcrypt y otros funciones de hashing de contraseñas usan sales e iteraciones para hacer frente a la debilidad inherente de las contraseñas, que es su vulnerabilidad a la búsqueda exhaustiva. El espacio de las posibles contraseñas, la que la mayoría de los usuarios escogerá y podrá recordar, es simplemente demasiado pequeño para su comodidad. Usamos iteraciones para que la tarea del atacante se ralentice. Usamos sales para que el atacante no pueda hacer economías de escala cuando intenta romper varias contraseñas. Pero todo esto tiene sentido solo porque es posible descifrar la contraseña una .

Cuando los datos que se deben eliminar (para la verificación ulterior) son una fuerte clave , elegidos uniformemente de un espacio lo suficientemente grande como para anular la búsqueda exhaustiva, las sales y el hashing lento no son necesarios. Este es el caso de su "UUID privado". Se supone que un UUID "v4" contiene 122 bits generados a partir de un PRNG criptográficamente fuerte. Esto va más allá de lo que es susceptible de una búsqueda exhaustiva. Este "UUID privado" es una clave en el verdadero sentido del término.

Entonces, en un protocolo dado donde hash estos "UUID privados" con bcrypt, puedes reemplazar bcrypt con una función de hash simple (por ejemplo, SHA-256) y olvidarte de las sales. En su caso, el servidor almacena h (UUID) para alguna función de hash h , vinculado a un usuario, y el usuario debe mostrar el UUID para que se le otorgue acceso. Este es el modelo simple de "contraseña" pero con una contraseña realmente fuerte, que no requiere las herramientas desarrolladas para tolerar las contraseñas recordadas por el hombre (que no son seguras). Por supuesto, querría ejecutar todo el protocolo bajo la protección de alguna capa, lo que garantiza que el cliente se comunique con el servidor correcto y que las transferencias estén protegidas contra escuchas y alteraciones (básicamente, SSL).