低:明文
中:使用密码加密,des/或它
高:base64(原文+时间+用户名+签名==私密(私或公)(md5(数据+时间+用户名))
sign生成步骤:
1、 将head和content拼成待加密串headcontent;
headcontent={"head":{"serCode":"A00001","merCode":"103100000000000","orderId":"00000000000000000000","merDate":"20121107","merTime":"131212","versionNo":"1.0.0"},"content":{******}}
2、 对headcontent(包括左右花括号{})做md5摘要,得到headcontent1;
3、 对headcontent1使用商户私钥进行加密得到sign。
4、 按字母顺序
Msg生成步骤:
1、 将head、content、和sign拼成msg1;
msg1={"head":{"serCode":"A00001","merCode":"103100000000000","orderId":"00000000000000000000","merDate":"20121107","merTime":"131212","versionNo":"1.0.0"},"content":{******},"sign":"******"}
2、 对msg1(包括左右花括号{})进行base64转码得到msg。
=================================
不是所有的都需要一个高级的安全实现。
内网明文,外网加密,敏感数据加签名(私匙、只有签名,内容明文)
=======================
具体的解决方案:在OpenAPI接口请求时,在url请求中对请求参数做MD5加密处理。 url请求参数包括:
user+pwd+date,这三个参数按照固定顺序做MD5加密,生成一个签名参数:sign,一个具体的请 求示例:
http://demo.xxx.net/user=test&date=2015-05-19 15:00:00&sign=AWEFJI32WEGFWEGW1133, 其中sign为字符串“user=test&pwd=
123&date=2015-05-19 15:00:00”的MD5值。服务端在接收到请求参数之后,先对用户 user=test的用户查找其密码,再构造
相同的字符串,然后MD5,根据请求的MD5与服务器的构造的MD5进行比对,来判断此次请求的合 法性,然后做进一步的业务处理。
协商、匹配
加密就不是明文的了,完整性可以使用内容加下前后缀来保证{xxx}。
签名是使用私钥,内容明文,md(),非对称为签名
ssl:密码是每次生成,签名是私钥。
简单有效