¿Es segura esta clave simétrica MAC-luego-encripta la metodología del token de autenticación? [cerrado]

-1
  

NOTA: Esta pregunta combinaba originalmente una "firma digital" y una "MAC", que desde entonces he aprendido que no son lo mismo. Cualquier referencia (en la respuesta o cualquier comentario) a una "firma" debe leerse como un "MAC".

Estoy experimentando con tokens de autenticación y estoy tratando de envolver mi mente en torno al mejor método.

Misiones

  1. Al iniciar sesión correctamente, se crea un token que contiene los usuarios accountID , un nonce y un expiry . Luego, el token se devuelve al cliente para usarlo en la próxima solicitud.
  2. El cliente devuelve el token al servidor con cada solicitud para identificar el origen ( accountID ) de cualquier solicitud dada.
  3. El token contiene un nonce que se cambia con cada solicitud.
  4. Se crea un MAC a partir del valor plaintext para garantizar que no se haya manipulado.
  5. El valor plaintext del token (incluido el MAC ) se cifra para garantizar que esté oculto de manera segura.
  6. El cliente nunca está al tanto de macKey o de encryptionKey . No se pretende que el cliente tenga acceso al contenido plaintext del token.

Método actual

///process.env.TOKEN_ENCRYPTION_PASSWORD = '13sd4089f-268c-483d-9e82-jk3c1b47c77a';
///process.env.TOKEN_MAC_KEY = '1fde05f4-268c-483d-9e82-85fc1b42321';

/// Successful login by user ...

var token = {
    nonce : 'SOME-UUID-GOES-HERE',
    accountID : 'account-12345',
    expires : 1234567890
};

token.mac = crypto.createHmac('sha512', TOKEN_MAC_KEY)
                  .update(JSON.stringify(token))
                  .digest('base64');

var encryptedToken = cryptoJS.AES.encrypt(JSON.stringify(token), TOKEN_ENCRYPTION_PASSWORD).toString();

response.send({
    message : 'Created, MAC'd, and encrypted an auth token.',
    authToken : encryptedToken
});

Preguntas

  1. ¿Es seguro, en este caso, emplear un método MAC-then-encrypt ? He leído varias opiniones sobre esto y me he ido más confundido que cuando comencé.
  2. He leído que cbc-mode debe usarse cuando se emplea un método MAC-then-encrypt . ¿Es este el modo predeterminado para CryptoJS.AES.encrypt() ?
  3. CryptoJS.AES parece bastante genérico. ¿Esta por defecto es AES256 ? ¿O es algo que debo declarar explícitamente en mi código?
  4. Al pasar una cadena a CryptoJS.AES.encrypt() , leí que genera automáticamente un key y iv 'detrás de escena'. ¿Sería más seguro generar mis propios key y iv , o debería dejar que CryptoJS maneje eso?
  5. ¿Se puede tener más seguridad empleando un método MAC-encrypt-MAC , o es simplemente agregando complejidad a la lógica de mi aplicación?
pregunta AJB 17.12.2016 - 02:31
fuente

1 respuesta

1
  1. Mac-then-Encrypt está perfectamente bien. Existe un ataque teórico en el que un esquema de Mac y luego Encriptación que usa un modo maleable (como CBC) puede ser posible para un atacante para manipular el texto cifrado para obtener un texto simple con la misma Mac, pero es solo teórico
  2. No está limitado al modo cbc, solo como un ejemplo TLS usa Mac-then-Encrypt y también se usa el modo CTR. Además, lo que CryptoJS hace de manera predeterminada es la implementación definida, lea la documentación, pero creo que CryptoJS.AES.encrypt() usará de forma predeterminada un cifrado de bloque único o BCE que no es seguro
  3. Documentación de nuevo
  4. La documentación es tu amiga
  5. No hay seguridad adicional, solo aumenta el tamaño de su mensaje sin ninguna razón. Ambos métodos Mac-then-Encrypt y Encrypt-then-Mac son igual de seguros por lo que sabemos. Incluso con el ataque teórico mencionado anteriormente

¿Lo único que no entiendo en tu esquema es por qué no lo haces? ¿Se utiliza para su negocio? ¿Es por algún tipo de supuesta "seguridad criptográfica"? ¿Se utiliza como token CSRF?

    
respondido por el Mr. E 20.12.2016 - 22:43
fuente

Lea otras preguntas en las etiquetas