动态口令设计系列一续：实际应用场景中对动态口令的一些误解

安全是一个木桶，必须保证每一块木板都足够完整坚固，才能达到期望的安全性要求。相当一部分的安全问题都是由系统的某方面安全短板导致的，所以我们在考虑系统安全性时，切忌只考虑某个方面，也不能天真地认为使用了某种方案就能一劳永逸解决所有问题，否则只会“按下葫芦浮起瓢”，白忙活。

本文是对上一篇文章 基于共享密钥的动态口令方案 的补充，列举一些实际应用场景我们可能存在的对动态口令的一些误解或者误用，持续更新中。

A、用静态口令作为共享密钥

有的开发人员可能为了图方便，使用静态口令（比如开放平台应用的app_secret）作为共享密钥，这是很不合理的。静态口令的信息隐秘等级应该高于共享密钥。

B、认为只把共享密钥用于参数签名就够了，不需要再加上动态口令，认为那样太麻烦

某些场景只将共享密钥用于参数签名是没问题。但另外一些场景的问题就大了。因为它忽略了动态口令的一次性和时效性带来的防重放作用。

举一个现实中的例子吧，比如手游的买道具扣金币功能，如果只将共享密钥用于参数签名，那么带签名的URL链接一旦被中间人攻击拦截，就可能导致重复扣金币。而如果使用上文提到的动态口令方案，先请求服务端生成一个动态口令，然后用动态口令连同其他请求参数用共享密钥签名后传给服务端，然后服务端进行扣费后就立即使动态口令失效。这样即使动态口令被拦截，由于攻击者不知道共享密钥一样无法利用。就算再进一步带动态口令参数的请求被拦截，攻击者由于不知道共享密钥也无法修改请求连接（一旦修改则服务端验证签名会失败），并且不能将这个链接重复请求（动态口令的一次性）。

所以手游中有价值的道具买入卖出、充值消费等都应该使用动态口令方案或者类似方案，而不能仅仅依靠参数签名来解决问题。

C、认为共享密钥生成算法绝对不能够公开

这点就不多说了。