¿Se utilizan hashes de hashes para el almacenamiento de contraseñas en la práctica? ¿Por qué por qué no? [duplicar]

Navega tus respuestas
2

Un desarrollador ingenuo podría almacenar una contraseña en la base de datos directamente, que luego se compararía directamente con la contraseña enviada desde un cliente. Un desarrollador más preocupado por la seguridad podría, en cambio, almacenar solo el hash de la contraseña en la base de datos y luego comparar el hash de la contraseña del cliente. Pero la mayoría de la gente usa las mismas contraseñas para sus cuentas. Como tal, a un sitio que requiere un correo electrónico y una contraseña para una cuenta / inicio de sesión se le puede dar acceso a todos los otros sitios para los cuales el usuario proporcionó la misma contraseña + correo electrónico.

Entonces, ¿qué pasaría si el cliente creara el hash? En este caso, el hash se enviaría al servidor, pero nuevamente no importa, si sé qué hash utilizas para iniciar sesión en google.com, el hash será el mismo para amazon.com (suponiendo que sea el mismo). algoritmo). Entonces, ¿qué hay de agregar una cadena desde el servidor a la contraseña, luego hashing? Ejemplo:

  1. Voy a amazon.com y me piden mis credenciales
  2. Con la página de inicio de sesión, amazon envía un guid: 'cdfefe81-d466-49a6-acea-140fa52c0901' (esto puede estar asociado con la cuenta de usuario, o simplemente tener 1 para todo Amazon)
  3. Ingreso mi contraseña, 'safe_password'
  4. El cliente agrega la guía para crear 'safe_passwordcdfefe81-d466-49a6-acea-140fa52c0901'
  5. Esto se aplica al hash utilizando el algoritmo de hash apropiado y luego se envía al servidor. Dentro del servidor, el hash se vuelve a hash (con un salt) y se compara con el hash en la base de datos para autenticar.

La ventaja de este flujo le permite al usuario usar contraseñas iguales o similares para múltiples servidores, y mientras todos esos clientes sigan este patrón, ningún servidor sabría la contraseña real del usuario, incluso si ese servidor estuviera comprometido.

Editar:

Para aclarar, el objetivo es proteger la contraseña del usuario, asumiendo que un servidor está completamente comprometido. Si ejecuto un sitio que requiere inicio de sesión, al recibir un hash con sal del cliente (donde proporciono el salt), incluso si un usuario malintencionado tiene acceso a todos los datos del lado del servidor, lo haría nunca podrá encontrar la contraseña original del usuario, suponiendo un buen hashing, lo que limitaría significativamente el impacto potencial para los usuarios por una violación de seguridad.

Otra aplicación sería los números de tarjeta de crédito, que son muy parecidos a las contraseñas. Imagínese este escenario: soy responsable de validar los números de las tarjetas de crédito en Visa para aprobar los cargos. Amazon quiere usar mi servicio, al igual que cualquier otro proveedor importante en el mundo. Así que le digo a Amazon "No autenticaré ninguna tarjeta de crédito directamente de un número. En cambio, requeriré que me envíes una versión de hash de una cadena, y desde que te registraste con nosotros como proveedor, aquí es un GUID que será asignado a su cuenta ". La cadena sería algo similar a <cc#>:<expiration>:<GUID supplied *to Amazon* by Visa> .

Así que todo este flujo:

  1. Amazon quiere procesar CC's, solicita GUID de Visa
  2. Visa genera GUID, envía a Amazon y asocia el GUID con la cuenta
  3. Amazon envía GUID con página de entrada de tarjeta de crédito al comprador
  4. En el lado del cliente, después de que se ingresa la información de CC, esta información nunca se envía a Amazon sin citar . En cambio, el cliente construye la cadena como se describe anteriormente, la procesa y envía el hash resultante a Amazon.
  5. Amazon quiere permitir que se repitan pedidos, por lo que almacena este hash en su base de datos.
  6. Para autenticarse, Amazon usa el modelo de autenticación S2S existente para probar que son Amazon.com, y envía el hash del cliente, junto con el nombre, la dirección, etc. del comprador.
  7. Visa recibe dicho hash, busca el GUID de Amazon y encuentra todas las tarjetas que son propiedad del comprador especificado. Para cada tarjeta del comprador, Visa reconstruye y vuelve a realizar el hash del número de tarjeta + fecha de exp + GUID de Amazon, y compara el hash con lo que se recibió de Amazon.
  8. Visa encuentra una coincidencia, dice que Amazon está bien para cargar esta tarjeta, y Amazon envía una confirmación de dicho cargo.

Dado este flujo, incluso si tuviera acceso a todas las bases de datos, servidores, discos duros, correos electrónicos, tráfico entrante, etc. de Amazon.com, nunca sabría el número de tarjeta de crédito del usuario . El mayor daño que podría infligir sería si puedo evitar ser un servidor de Amazon.com, puedo cobrarle al usuario en nombre de Amazon.com, pero eso presumiblemente entraría en la cuenta de Amazon.com, por lo que Es probable que no se beneficie de esto en absoluto. En una situación ideal, este flujo sería parte de la lógica SSL, de modo que solo el sitio que implemente algo de esta naturaleza reciba el símbolo de bloqueo en los navegadores del cliente (no lo he pensado completamente, pero parece plausible)

    
pregunta Rollie 24.05.2015 - 12:55
fuente

2 respuestas

2

Su esquema no funcionaría tal como es, porque el servidor de Amazon no lo ha autenticado aún cuando llega a la página de inicio de sesión. Por lo tanto, debe permitir que el navegador de su cliente decida cómo crear una guía única. Si el servidor intentara calcular una guía única basada en atributos conocidos, como su dirección IP o la huella digital del navegador, no podrá conectarse desde múltiples dispositivos o ubicaciones.

Todos los navegadores en todos los dispositivos tendrían que procesar las guías de manera similar para que los usuarios puedan obtener una guía consistente. Eso significa que los usuarios se autenticarían en su propio dispositivo, de una forma u otra. Supongamos que el guid es una combinación de una credencial de usuario que se transmite al navegador y el nombre de dominio de cada sitio web para evitar la suplantación de identidad. Ahora puede crear contraseñas únicas, con dos fuertes restricciones:

  1. no manejas sitios que tienen múltiples nombres de dominio
  2. necesitas equipo compatible

El primer problema podría solucionarse haciendo que los navegadores y los sitios comuniquen las listas de dominios de confianza, al igual que para la Política del Mismo Origen, y las API públicas para que los navegadores consulten los dominios de confianza de un dominio "primario" utilizado como semilla para la algoritmo guid. Esto es principalmente infraestructura, nada imposible.

El segundo problema es más serio. Su objetivo original es hacer que la suplantación de contraseñas sea inútil, o en otras palabras, hacer que todos los clientes generen credenciales únicas por usuario / dominio (en cuyo caso, por cierto, se reemplaza la idea de una contraseña). Si se adoptara, necesitaría que todos los sitios web y todos los clientes fueran compatibles de inmediato. De lo contrario, los usuarios encontrarán situaciones en las que deberán proporcionar una contraseña única basada en guid a un sitio pero no podrán calcularla, o donde podrán calcular una contraseña basada en guid pero tendrán que usar una contraseña antigua y eliminable.

Observe cómo importó uno de los principales problemas de los administradores de contraseñas que crean contraseñas únicas: ¡debe mantener el acceso al administrador para evitar el bloqueo! Si desea mantener una capa de compatibilidad que le permita conectarse con su antigua contraseña robable, entonces esa contraseña podría ser falsificada y reutilizada.

Sin embargo, todavía hay una aplicación para su idea: el hecho de que el guid sea único, además de una contraseña original, puede dar a los sitios web un grado de confianza un poco más alto de que usted es un cliente legítimo y no una parodia. Esto suena bien, pero no es necesariamente suficiente para los grandes proveedores de servicios, que a menudo se enfrentan a dispositivos comprometidos, y no solo con contraseñas robadas. Un dispositivo comprometido proporcionaría a un atacante un medio para generar todas sus guías para todos sus sitios web (ya que su secreto puede ser extraído). Al final, tienes los mismos inconvenientes y la misma superficie de ataque que un administrador de contraseñas, ¡porque eso es lo que has creado!

    
respondido por el Steve DL 24.05.2015 - 14:42
fuente
0

Todavía pienso, el problema aún no se ha abordado. ¿Cuál es el activo que está tratando de proteger? ¿La contraseña o el hash de contraseña? ¿Es el hash de contraseña / contraseña almacenada o durante el tránsito?

Algunos requisitos de desconexión / o claridad

  

Voy a amazon.com y me piden mis credenciales.    Con la página de inicio de sesión, amazon envía un guid: cdfefe81-d466-49a6-acea-140fa52c0901 '(esto puede estar asociado con la cuenta de usuario, o simplemente tener 1 para todo amazon)

No estoy seguro de cómo identificar al cliente. Posiblemente, si tiene el servidor para pedir el nombre de usuario y la contraseña uno a la vez, esto podría funcionar, pero si los campos de nombre de usuario y contraseña se atienden desde la misma página, es posible que no. Mantenerlo igual para todos los usuarios podría anular el propósito.

La clave es, este debe ser un proceso repetible en todos los dispositivos, clientes conocidos / desconocidos, etc. y no es

  

Ingreso mi contraseña, 'safe_password'. El cliente agrega el guid para crear 'safe_passwordcdfefe81-d466-49a6-acea-140fa52c0901'. Esto se procesa utilizando el algoritmo de hash que sea apropiado y luego se envía al servidor. Dentro del servidor, el hash se vuelve a hash (con un salt) y se compara con el hash en la base de datos para autenticar.

Entonces, si la contraseña 'safe_password' está en manos de un atacante a través de un sitio web comprometido, ¿este proceso lo detendría de la cuenta de amazon.com?

Esta solución podría tener un lugar, como los entornos autenticados en la máquina cliente.

    
respondido por el knight007 24.05.2015 - 16:38
fuente

Lea otras preguntas en las etiquetas

¿Cómo afecta el ataque 'Logjam' a openID ya que usa el método de intercambio de claves Diffie-Hellman? ¿Cómo obtengo la huella digital de una clave pública SSH2 en Windows?