关于服务端数据加密

前言

目前的情况下API被很多地方应用，随之而来的是API的安全性问题。安全性问题有以下几个方面：
*> DDoS(拒绝服务攻击)，接口被恶意调用，使真实的用户无法享受到正常畅通的服务。这个比较单纯，也比较容易处理，通过IP限制来做，并且辅以一些硬件设备应该就没问题了，同时服务器供应商也可以提供相应的服务。

• 传输过程中数据被截获，http数据包是可以被截获到的，这一点我们无法防止，能做的只有使被截获到的数据对截获者来说无意义。这个问题要分成两种情况来说明，第一种情况，api站点采用了https，那么在网络中传输的数据就是被加密过的数据，这种数据截获者很难把他解密出来，所以可以保证数据的安全性。第二情况，api站点没有采用https，而是使用的普通的http，如果不加任何处理其实传输的数据是在裸奔，当然有些数据就是给截获者截获到也没有什么影响，但对于敏感的信息我们还是要想办法来处理下的，要么协商一种相同的加密方法，这样起到加密作用。另外请求时使用token不直接传以明文密码暴露的机会，同时最好是在传输前就把信息MD5一下，这样对用户的在网站上的安全性是有好处的。总的来说不使用https的传输是不安全的，有意义的敏感信息有可能会被截获到，建议在登录相关的接口有条件时一定使用https，如果使用http登录也一定要处理一下敏感信息，比如这样MD5(变形(MD5(原文)))，这样即使被截获也可以保证截获人不能得到原文，也就保证了用户在其他网站上帐号的安全。
• 伪造请求，在上一种情况的基础上，截获者可以利用截获到的数据发起伪造的请求，当然https不会有这个问题。解决这个问题的一个方法是，让请求成为一次性的或者说只能在短时间内有效，可以在参数中再加入一个签名（sign），签名是由时间戳加参数MD5构成的，这样可以在服务端验证其有效性与时效性，这个方法在他人不知道签名生成规则时是有效的。但是如果程序被反编译就可以比较容易的知道生成规则。更靠谱一点的话就在生成sign时增加key值（不过这对app并不是太适用，因为如果key改变就要更新app），不过这样还是躲不过反编译，于是防止反编译也是重要的一环了。另外的一个途径是保证数据确实是从真实的客户端发出来的，这个就要从token上想办法了，例如对比IP，但这种途径显得比较苍白无力同时有局限性（如第一次登录，同时IP在实际情况下发生变化也不应该被认为不合法）。还有可以在重要的操作时应用二次授权，这样可以降低风险。**
  　　

解决的方案

• 传输中加上签名sign不是为了防止被截获，而是为了防止被篡改或发出伪造请求。
• 数字签名是对所传输数据的散列后的摘要使用私钥加密得到的结果，数字签名使得接收方可以确认信息是可靠的，因为只有指定私钥加密的内容接收方才可以解密出来。对于指定的MD5结果，可以有方法找到多个文本与之对应。即单次单纯的MD5是不够安全的，可以通过MD5(变形(MD5(原文)))来解决这个问题。
• 数字证书是由权威机构用自己的私钥加密服用提供方的公钥并搭载其他相关信息组成的。
• 使用token是为了唯一标识用户，应该在数据库中维护这些数据，它应有的关联属性（用户ID、IP、到期时间、是否有效）

总结更合理的实现方案

使用对称加密加密与解密使用的是同样的密钥，速度快，但由于需要将密钥在网络传输，所以安全性不高；非对称加密使用了一对密钥，公钥与私钥，安全性高，但加密与解密速度慢。

解决的办法是将对称加密的密钥使用非对称加密的公钥进行加密，然后发送出去，接收方使用私钥进行解密得到对称加密的密钥，然后双方可以使用对称加密来进行沟通。虽然非对称加密很安全，但是和对称加密比起来，它非常的慢，所以我们还是要用对称加密来传送消息，但对称加密所使用的密钥我们可以通过非对称加密的方式发送出去。

流程过程：

• APP客户端需要和服务器进行数据交互，它的APP首先生成了一个随机数作为对称密钥(比如AES加密的密钥)。
• APP客户端向服务器请求公钥。
• 服务器将公钥发送给APP客户端。
• APP客户端使用服务器的公钥将自己的对称密钥(比如AES加密的密钥)加密。
• APP客户端将加密后的对称密钥发送给服务器。
• 服务器使用私钥解密得到APP客户端的对称密钥。
• APP客户端与服务器可以使用对称密钥来对沟通的内容进行加密与解密了。