¿Debo ofuscar las contraseñas antes de hash? ¿Debo pre-hash en el cliente? ¿Qué pasa con las sales?

11

Por diversión, y en mi tiempo libre, estoy creando un CMS simple para mis propios fines (con la esperanza de lanzarlo para un uso más amplio ... más adelante), usando PHP. Actualmente estoy trabajando en el esquema de inicio de sesión y tengo algunas preguntas.

Nota: El resultado final siempre se transmite a través de crypt utilizando blowfish y un parámetro de coste de 15 (En general, la esperanza de que un parámetro de costo de 15 sea suficiente para dañar los intentos de piratería, pero no lo suficiente como para frustrar a los usuarios).

Pregunta 1: Suponiendo que estoy usando SSL / TLS: ¿Realmente necesito ofuscar la contraseña, antes de pasarla a bcrypt (con los parámetros dados y la sal adecuada) y presionarla? a la base de datos?

Pregunta 1.a: Como no tengo acceso a SSL / TLS (por el momento, mi Webhost es demasiado costoso), está usando hash whirlpool (o algo de la familia sha-2) del lado del cliente en la contraseña antes de pasarla al servidor, un caso" suficientemente bueno "de ¿Seguridad, o ese hash es vulnerable a los ataques de la mesa del arco iris? (Esto supone que estoy tratando de poner una solapa en una tienda, no en una bóveda de un banco. Las bóvedas de un banco pueden permitirse SSL / TLS).

Pregunta 2: vale la pena crear un nuevo salt para la contraseña cada vez que el usuario vuelva a iniciar sesión, o simplemente necesito crear un salt único para ese usuario de entropía adecuada cuando se registran, y lo dejan?

    
pregunta Mike S 25.04.2011 - 20:06
fuente

4 respuestas

12

P1: "ofuscar" la contraseña no le ofrece nada aquí, en términos de seguridad; simplemente hace que el código sea más complejo, lo cual es una mala idea.

Q1a: El hash de la contraseña es "equivalente a la contraseña": presentarla es suficiente para autenticarse. Así que el hashing no cambia nada a la seguridad: esto es equivalente a intercambiar la contraseña en texto claro. Por seguridad, realmente desea utilizar SSL, no obtendrá mucha seguridad sin él. En realidad, puede olvidarse de todo sobre crypt() y Blowfish y el recuento de iteración "15" hasta que haya habilitado SSL: la falta de SSL es un problema de seguridad mucho más amplio. crypt() con Blowfish es muy bueno, pero usarlo sin una transferencia de contraseña protegida por SSL es como poner un candado de acero en la solapa de una tienda.

P2: El punto del salt es ser único por instancia de contraseña; una sal aleatoria suficientemente grande asegura tal singularidad "probabilísticamente". Así que cambia la sal cada vez que creas y cambias una contraseña (es decir, cuando agregas una nueva cuenta de usuario o cuando un usuario cambia su contraseña). No es necesario volver a introducir una contraseña que no cambie.

    
respondido por el Thomas Pornin 25.04.2011 - 21:55
fuente
3

P1: Suponiendo que lo estás haciendo de la manera "convencional":

  • un usuario final completa un formulario HTML,
  • que se sirve a través de HTTPS,
  • la respuesta va a través de HTTPS a su servidor de aplicación web,
  • que está conectado a su servidor de base de datos a través de una red confiable (es decir, tanto el servidor de aplicación web como el servidor de base de datos son sistemas seguros en una LAN segura)

entonces no, no ofrezca la contraseña antes de que llegue a su código de aplicación web (PHP) en el formulario de envío.

Pero, estás planeando usar PHP crypt (), que te ofrece varias maneras de meterte en problemas, f.x. utilizando MD5. ¿Por qué no usar una biblioteca de nivel superior optimizada para el almacenamiento seguro de contraseñas? No soy programador de PHP, pero PHPass parece una opción común, utilizada por fx Wordpress. De lo contrario, consulte "Desbordamiento de pila" para "PHP bcrypt" o "PHP scrypt".

Q1a: Aquí no hay seguridad si no estás usando HTTPS. Su analogía con la "tapa de la tienda de campaña" es acertada, ni siquiera va a detener a los niños con pedernales ... Básicamente, no haga esto. Y si lo hace, deje todos los pensamientos sobre el hash en el lado del cliente "por seguridad". Cambie a un host web que ofrezca HTTPS.

P2: Solo creas una nueva sal si / cuando el usuario final cambia su contraseña. Nunca lo cambie, de lo contrario, el salt es necesario siempre que verifique una contraseña de usuario (es decir, cada vez que un usuario inicie sesión), por lo que con un salt incorrecto, los usuarios no pueden iniciar sesión.

    
respondido por el Jesper Mortensen 25.04.2011 - 21:26
fuente
0

P1: en teoría, no es necesario que ofuscas la contraseña, aparte de agregar sal antes de hacer hash. Esto solo aumentará la complejidad, no el valor de seguridad.

Q1.a: el hash de la contraseña antes de enviarla a través del cable solo evitará que un intruso lea la propia contraseña. No protegerá de la reproducción del hash y de iniciar sesión como ese usuario. La conexión realmente debería ser sobre SSL.

    
respondido por el Steve 25.04.2011 - 21:04
fuente
0

1) no. La ocultación es más para que los administradores no puedan decir cuál es la contraseña

1a) DEJEMOS DEJARSE: siempre debes, siempre, usar SSL.

Una mejor pregunta es; Que tiene la misma respuesta es; digamos que usted tiene una conexión SSL con un proveedor externo debido a los acuerdos de su contrato con ellos, pero no quiere correr el riesgo de que rastreen la información de sus usuarios (contraseñas, nada). y fuera del honor de los exploradores, no confías en ellos. Junto con eso, puedes usar un canario en el campo de entrada para asegurarte de que es el usuario al que enviaste los datos también.

Respuesta: Puedes hacer criptografía de clave pública en el lado JS antes de enviar los datos. Esta NO es la misma seguridad que SSL, pero proporciona otro nivel de seguridad que se puede usar.

He estado en esa situación, donde el socio tenía los certificados SSL y podía detectar nuestros datos, y usamos un sistema como ese.

    
respondido por el Jdahern 06.05.2014 - 23:58
fuente

Lea otras preguntas en las etiquetas