contraseñas doble dispersión - cliente y servidor

Question

Hola, en primer lugar, permítanme decir, no estoy preguntando por cosas como MD5 (MD5 (..., ya hay temas al respecto

Mi pregunta es la siguiente:.

Permitimos que nuestros clientes almacenen sus contraseñas localmente. Naturalmente, no queremos que estén almacenadas en el texto del plan, por lo que las procesamos localmente, antes de almacenarlas y enviarlas. Ahora, esto está bien, pero si esto es así todo lo que hicimos, entonces el servidor tendría el hmac almacenado, y como el cliente solo debe enviar el hmac, no la contraseña de texto plano, un atacante podría usar los hashes almacenados del servidor para acceder a la cuenta de cualquier persona (en el escenario catastrófico donde alguien tendría acceso a los datos e, por supuesto).

Por lo tanto, nuestra idea era codificar la contraseña en el cliente una vez a través de hmac, enviarla al servidor, codificarla por segunda vez a través de hmac y hacerla coincidir con la contraseña almacenada, dos veces hmac'ed. Esto garantizaría que:

• El cliente puede almacenar la contraseña localmente sin tener que almacenarlo como texto sin formato
• El cliente puede enviar la contraseña sin tener que preocuparse (demasiado) sobre otras partes de la red
• el servidor puede almacenar la contraseña sin tener que preocuparse de que alguien le robe desde el servidor y utilizarlo para conectarse.

Naturalmente, todas las otras cosas (contraseñas fuertes, sal doble, etc.) se aplican también, pero no son realmente relevantes para la pregunta.

La pregunta real es: ¿suena esto como un diseño de seguridad sólido? ¿Pasamos por alto algún defecto al hacer las cosas de esta manera? ¿Hay quizás un patrón de seguridad para algo como esto?

Adición: la razón por la que no queremos almacenar localmente la contraseña en texto plano en el cliente es porque, aunque es triste, muchas personas todavía usan la misma contraseña para múltiples servicios, por lo que obtienen la contraseña 'real' Sería una violación de seguridad más grande para el usuario que obtener su hash robado.

Answer 1

Como han dicho otros, tomar al cliente y su sistema en aislamiento esto realmente no le compra nada - el primer hash simplemente se convierte en la contraseña.

El valor viene si (como es probable) el cliente usa esa misma contraseña en otros sistemas. En este caso, si la máquina del cliente se ve comprometida, al menos su copia local de su contraseña hash no le permite al atacante acceder a otros sistemas. Obviamente, el atacante del cliente será ahora podrá acceder a su servidor; después de todo, han obtenido la contraseña.

Un atacante que tenga acceso al valor double-hashed en el servidor no les comprará nada, ya que no pueden revertir eso para obtener el hash único (es decir, la "contraseña"). Por supuesto, si el atacante está en posición de leer su base de datos de seguridad, entonces sospecho que tienen otros vectores de ataque disponibles :)

Además, como dijo otro cartel, asegúrese de estar usando sal en ambos valores hash. Sin hacerlo, invertir los valores hash puede ser bastante simple si las contraseñas no son fuertes.

EDITAR - en realidad, pensando en ello, ya que está utilizando un hash como la contraseña que realmente no necesita utilizar una sal en el servidor. De ninguna manera alguien podrá crear una tabla de arcoíris que sea efectiva :) Aún así necesitamos una en el cliente.

Answer 2

Advertencia: No soy un experto en seguridad. Voy a hacer ping blowdart para ver si se imagina participar.

Si el cliente está simplemente almacenando el hash, y transmitir con eficacia algo simplemente basa en el hash, entonces están efectivamente almacenarlo en texto plano . El único beneficio que proporciona el primer hash es que si han utilizado la misma contraseña en un sistema diferente, ese otro sistema no se verá comprometido si se revela el hash.

Dicho de otra manera: si alguien puede hacerse con el hash que está almacenado en el servidor, eso es todo lo que necesita para iniciar sesión en el sistema ... al igual que el almacenamiento de texto sin formato.

Answer 3

No estoy exactamente seguro de lo que esto te compra para almacenar la contraseña localmente en texto plano.

El propósito del cifrado local es evitar que un pirata informático pueda enviar la contraseña a su servidor. Sin embargo, si va a enviar el formulario encriptado a través de ... bueno, no ha comprado nada.

En su lugar, la máquina local debe almacenar la contraseña en un formato cifrado bidireccional. Lo que significa que puede ser descifrado. Que haces antes de la transmisiónEl archivo db puede almacenar un formato encriptado unidireccional (incluso usando un mecanismo de cifrado separado). Antes de la comparación, encriptas lo que recibiste y luego verificas.

Answer 4

¿Cuál es el hash inicial de la contraseña destinada a lograr? Protegerá contra el descubrimiento de la versión de texto sin formato de la contraseña. No impedirá el uso de ese valor hash para calcular el valor double hashed.

Answer 5

No, esto no es seguro. El valor hash es efectivamente la contraseña. El hecho de que la contraseña se derivó de otra cosa que el usuario considere la contraseña no importa. Es un valor secreto que autentica a un usuario, ¿verdad? Me parece una contraseña.

Creo que se basa en la afirmación: "Naturalmente, no queremos que estén almacenados en el texto del plan, por lo que los procesamos localmente, antes de almacenarlos o enviarlos". Si el sistema se altera para que la contraseña hash ahora tenga la misma potencia que la contraseña, se debe usar el mismo nivel de precaución con la contraseña hash.

Answer 6

Me estoy quedando sin la puerta, pero el Skeet hizo un ping y no te metas con el Skeet.

Lo que está haciendo es reemplazar una contraseña con otro valor constante. Aquí no gana nada, la única seguridad que tiene es que no se puede descubrir la contraseña de texto sin formato en la máquina cliente.

Lo que parece que hace es tratar el HMAC (¿está seguro de que quiere decir HMAC? En caso afirmativo, ¿de dónde viene y se almacena la clave?) De la contraseña como la contraseña en sí, lo envía desde el cliente al servidor donde se usa para autenticarse. El segundo HMAC o hashing no tiene sentido, estás comparando con el valor enviado, es una contraseña con cualquier otro nombre. Entonces, como atacante, en lugar de robar la contraseña, solo necesito robar el HMAC almacenado en la máquina del cliente. Aquí no se gana nada.

Answer 7

blowdart golpeó el clavo en la cabeza - solo está cambiando el secet para robar, no asegurando nada. Lo que está tratando de para replicar es un antiguo protocolo de autenticación que no puedo recordar por el nombre de mi vida.Así es como funciona:

Tras la inicialización, el servidor obtiene su contraseña, iterativamente hashed n veces, representada por F _n (pase). El cliente tiene la contraseña y el número n.

Usted va a autenticarse, y envía el servidor F _n-1 (pase) - es decir, la contraseña hashed n-1 veces. El servidor lo haste una vez más, lo compara con F _n (pase) y si coinciden, obtiene acceso. El servidor luego reemplaza F _n (pase) con F _n-1 (pase) y usted disminuye n.

La próxima vez que vaya a autenticar, envíe F _n-2 (pase) y el proceso se repite.

Vamos a examinar la seguridad:

• MITM: ninguna resistencia incorporada en el protocolo, habría que colocarlo en la capa interior de SSL
• ataques de repetición: no trabajan, ya que el servidor ha disminuido las iteraciones hash.
• Escuchas: La siguiente autenticación se realizará mediante F _n-1 (pase). Tiene F _n (pase). Pasar de F _n (pase) a F _n-1 (pasa) es, por definición de la función hash, no factible
• Poseer el servidor: Usted no sabe la contraseña del cliente, ni se puede autenticar como ellos, porque una vez más se necesitaría F _n-1 (pasa) cuando sólo se tiene F _n
• Poseer el cliente: ya que almacenar F _n-1 (pasa) (por lo que no tienen para ingresar el pase) - entonces ser dueño del cliente permitiría que el atacante inicie sesión. Si solo almacena n y no la contraseña, esto se evitaría, pero es evidente que desea guardar la contraseña.

Eso es lo que estás tratando de lograr. Sin embargo, hay una razón por la cual este protocolo no está en uso: es una perra gigante para sincronizar. Si el cliente y el servidor no se sincronizan debido a un paso a medio completar, estás bloqueado. Cualquier resistencia que hayas incorporado para evitar eso probablemente reduzca la seguridad para reproducir o escuchar a escondidas.