Usando bcrypt en la extensión de Chrome [cerrado]

0

Estoy desarrollando una extensión de Chrome para esta organización sin fines de lucro. También estoy trabajando en el componente del lado del servidor también. No soy un desarrollador a tiempo completo, así que la mayor parte de mi conocimiento simplemente proviene de años de recopilación de información aleatoria. Una cosa que este programa debe hacer es iniciar sesión en el servidor y recuperar un código único para el usuario. Afortunadamente, según cómo funciona en mi mente, no necesitamos almacenar la contraseña, solo recuperar y almacenar su ID única. Sin embargo, tendremos que iniciar sesión para obtener esa ID.

Entonces, mi pregunta es si utilizo bcrypt en javascript para modificar la contraseña dentro de la extensión y luego enviar el correo electrónico + hash al servidor (por supuesto, a través de https), ¿existe algún riesgo de seguridad aquí? No estoy pensando en uno fuera de lo alto de mi cabeza, pero simplemente pensé que consultaría a algunas personas que viven en este mundo de forma regular. ¡Gracias!

    
pregunta stevo81989 20.01.2015 - 00:56
fuente

2 respuestas

1

¿Existe un riesgo de seguridad? No.

¿Hay una ventaja de seguridad? No.

El uso de HTTPS significa que la contraseña está protegida en tránsito y que se está enviando al servidor que desea. Hashear la contraseña del lado del cliente y enviar el hash no gana nada: un atacante que puede mirar dentro del túnel SSL y robar una contraseña de texto sin formato (por ejemplo, el malware instalado en el cliente) puede, en cambio, robar el hash y pasarlo cuando se hace pasar por la suplantación el usuario.

Como nota al margen, hay problemas con el hashing o el cifrado en Javascript. El uso de una extensión de navegador en lugar de Javascript en la página evita muchos de ellos, pero todavía hay un problema de velocidad: Javascript es lento en comparación con el código nativo, por lo que no puede permitirse el lujo de realizar tantas rondas de hash bcrypt.

    
respondido por el Mark 20.01.2015 - 04:10
fuente
0

Lea la respuesta canónica de Thomas Pornin a Cómo codificar de forma segura las contraseñas , en particular la sección

  

Dado que el hashing es (deliberadamente) costoso, podría tener sentido, en una situación cliente-servidor, aprovechar la CPU de los clientes conectados. Después de todo, cuando 100 clientes se conectan a un solo servidor, los clientes colectivamente tienen mucho más poder que el servidor.

     

Para realizar el hashing del lado del cliente, el protocolo de comunicación debe mejorarse para admitir el envío del Salt al cliente. Esto implica un viaje de ida y vuelta adicional, en comparación con el simple protocolo cliente-envío-contraseña-servidor. Esto puede o no puede ser fácil de agregar a su caso específico.

     

El hashing del lado del cliente es difícil en un contexto web porque el cliente usa Javascript, que es bastante anémico para las tareas que requieren un uso intensivo de la CPU.

     

En el contexto de SRP, el hashing de contraseña necesariamente ocurre en el lado del cliente.

El resultado final es que puede sentirse libre de realizar el hash del lado del cliente, SIN EMBARGO, esto no cambia los requisitos para el hash del lado del servidor de resultados antes del almacenamiento en una base de datos u otro almacén de datos .

No importa lo que el cliente le envíe para validar quiénes son, debe codificarlo en el lado del servidor con una gran cantidad de iteraciones de PBKDF2, BCrypt o SCrypt, para que alguien con una copia filtrada de su base de datos de autenticación / contraseña Aún debe realizar una cantidad significativa de trabajo para autenticarse en su aplicación.

Es necesario almacenar el ServerBcrypt (ClientBcrypt (password, lots), evenmorelots), el recuento de iteración / factor de trabajo y las sales para tener algo para autenticar lo que el presunto usuario le proporcione.

    
respondido por el Anti-weakpasswords 20.01.2015 - 05:49
fuente

Lea otras preguntas en las etiquetas