这个对称密钥MAC然后加密令牌方法是否安全？

Question

注意:这个问题最初把“数字签名”和"MAC“混为一谈，而我后来了解到，这并不是一回事。对“签名”的任何提及(在答复或任何评论中)都应理解为"MAC“。

我正在试验奥斯代币，我正试着用最好的方法来解决这个问题。

目标

1. 成功登录后，将创建包含用户accountID、nonce和expiry的令牌。然后将令牌传递回客户端，用于下一个请求。
2. 客户端将令牌与每个请求一起传递回服务器，以标识任何给定请求的来源(accountID)。
3. 该令牌包含一个随每个请求而更改的值。
4. MAC是从plaintext值创建的，以确保它没有被篡改。
5. 然后对令牌的plaintext值(包括MAC)进行加密，以确保其安全模糊。
6. 客户端从来不了解macKey或encryptionKey。客户端不打算访问令牌的plaintext内容。

电流法

///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
});

问题

1. 在这种情况下，使用MAC-then-encrypt方法安全吗？我读过一些关于这方面的意见，比我开始的时候更困惑地走开了。
2. 我已经读过，在使用cbc-mode方法时应该使用MAC-then-encrypt。这是CryptoJS.AES.encrypt()的默认模式吗？
3. CryptoJS.AES似乎相当通用。这是默认的AES256吗？或者这是我需要在代码中明确声明的东西吗？
4. 当将字符串传递给CryptoJS.AES.encrypt()时，我看到它会自动生成一个“幕后”的key和iv。生成自己的key和iv会更安全吗?还是应该让CryptoJS来处理呢？
5. 通过使用MAC-encrypt-MAC方法可以获得更多的安全性，还是仅仅增加了我的应用程序逻辑的复杂性？

Answer 1

1. 麦克-然后-加密是非常好的。在一种理论攻击中，使用可扩展模式(如CBC)的Mac加密方案可能会被攻击者篡改密文以获得同一个Mac明文，但这只是理论性的攻击。
2. 您不仅限于cbc模式，就像TLS使用Mac-然后加密和CTR模式一样。此外，默认情况下，CryptoJS所做的是定义实现，阅读文档，但我认为CryptoJS.AES.encrypt()默认为单个块加密或不安全的ECB。
3. 文件再一次
4. 文档是你的朋友
5. 没有额外的安全性，只是增加您的消息的大小没有任何理由。据我们所知，这两种方法都是同样安全的。即使前面提到的理论攻击

在你的计划里我唯一不明白的就是为什么现在？用在你的生意上？是为了某种所谓的“密码安全”吗？它被用作CSRF令牌？