Security hmac键和盐长度

我正在使用hmac sha1对传递给第三方服务的用户ID进行签名。 相同的秘密用于所有用户，salt对于每个用户都是唯一的

token = userid : timestamp+2hours : hmac(userid : timestamp+2hours, salt+secret)
token_hex = hex(hash)

hmac适用于短字符串吗？userid:timestamp可以是例如12:1304985212 盐和秘密的顺序重要吗？（盐+秘密vs秘密+盐） 共享秘密的长度应该是多少，salt的长度应该是多少？ 我是否可以使用相同的密码在服务器和远程服务之间对消息进行签名，还是生成单独的密码更好

谢谢

您应该计算hmac（salt:userid:timestamp+2hours，secret）并传输salt:userid:timestamp+2hours:hash。 salt在这里的目的是使明文更长，不重复，所以最好将其附加到明文中，而不是秘密

---

如果您真的想更改机密，请执行hmac（userid:timestamp+2hours，hash（salt:secret）），这将使一次性机密看起来更像随机数。

将salt添加到明文部分是有意义的。如果我在服务器和远程服务之间传输salt或离线传递salt（如机密）有关系吗？这个秘密有可能被破解吗？您的第二个示例对此进行了保护，但您的意思可能是：hmac（salt:userid:timestamp，hash（salt:secret））。在这种情况下，我真的需要hmac吗，或者拥有sha1（userid:timestamp:salt:secret）就足够了吗？您不能以有用的方式将salt离线传递：salt必须是随机的，并且只能使用一次，每次消息都会更改。所以在使用和传输数据之前，您只能从随机数生成器中获取它。盐没有什么秘密，除非它每次都变。实际上，如果您每秒发送的消息不超过一条，则根本不需要单独的salt：hash（timestamp）就足够了。无法从HMAC结果中提取机密，您唯一的风险是从服务器中窃取机密。第二个示例只是通过每次提供新的秘密而不是新的明文来使HMAC不重复。使用时间戳而不是哈希（时间戳）作为salt和usersecret+globalsecret来防止彩虹攻击有什么错？如果使用单独的salt，这里没有错。Hash（timestamp）仅用于salt：将时间戳序列中的1位差异分散到长Hash结果上并不是坏事。我不理解您最后的评论。盐是好是坏？散列（时间戳），因为盐更好？