安全验证问题

安全问题

当APP向全媒体系统提交HTTP请求时， 必须 附带若干URL参数，作为验证依据。

全媒体系统在收到请求时，会进行验证，并拒未通过绝验证的请求。

参数

timestamp 时间戳 形如： 1407812629434 注释：Java中的获取方法 – Date().getTime()

signature 签名  签名由 APPID , APPSECRET , timestamp 计算得出

算法
APP应将 signature 参数填写为 SHA1 哈希值的16进制字符串表达式

[Math Processing Error]
以 Python 语言举例:

>>> from hashlib import sha1
>>> appid = b'1001'
>>> appsecret = b'123456abcdef'
>>> timestamp = b'1407812629434'
>>> signature = sha1(appid + appsecret + timestamp).hexdigest()
>>> print(signature)
b1d11d44bcb28caa6ce4dc1b7f1526ede00f49e0
此时，url形如:

http://api/v1.0/1001/staffService/message?timestamp=1407812629434&signature=b1d11d44bcb28caa6ce4dc1b7f1526ede00f49e0
APP的安全验证
全媒体系统向APP发送HTTP请求是，也会在URL的参数部分附带验证数据。APP可以根据这些参数进行验证。

参数 

 timestamp  时间戳  形如： 1407812629434

 signature 签名  签名由 APPID , ACCESSTOKEN , timestamp 计算得出

算法
全媒体系统将 signature 参数填写为 SHA1 哈希值的16进制字符串表达式

[Math Processing Error]
以 Python 语言举例:

>>> from hashlib import sha1
>>> appid = b'1001'
>>> accesstoken = b'6c9hgd@%#^5evc75@53Z5'
>>> timestamp = b'1407812629434'
>>> signature = sha1(appid + accesstoken + timestamp).hexdigest()
>>> print(signature)
04326e341d0ba7064975a9c03a75361f856d3341
此时，url形如:

http://apphost/staffService/message?timestamp=1407812629434&signature=04326e341d0ba7064975a9c03a75361f856d3341

 

 

Both timestamp and nonce are ways to prevent a man in the middle attack on an authentication mechansim. They work slightly differently, but the intent is the same - to provide a peice of data that is cryptographically built into the authentication mechanism that would make it difficult or impossible for an attacker to attack the system by replaying the message. A typical mechanism is authentication via digital signature. In either case, here's the steps:

1 - make message, attach timestamp or nonce to message

2 - hash both the message and the timestamp or nonce

3 - encrypt the hash with the private key (ie, sign it)

4 - send signature and message and nonce/timestamp

(this is the point at which the attacker gets a hold of it.

5 - recipient gets message.

6 - recipient checks that the signature matches the sent data (repeat step 2, decrypt signature with public key, compare to hash)

7 - recipient checks timestamp or nonce:

a - check timestamp - the value of the timestamp must be within an acceptable range of the current time. Ideally, the whole system is served by a timestamp server that defines to a tight precision what the "current time" is. If not, the system risks false negatives where the recipient incorrectly decides that the message time stamp is too old (or hasn't yet occured) do to a current time mismatch.

b - check nonce - verify that the nonce that was received has never before been received from this sender. Since the hash is unique to the contents of the message, this message MUST have come from the authorized sender, because this message is not being replayed.

8 - recipient performs any further authorization and access control checks.

The important things are:

either the timestamp or the nonce MUST be part of the signature
the timestamp is good if you are concerned about replay within a given time, but it requires good synchronization between servers and it will always assume some spectrum of error as many messages may be sent in a current spectrum of time - for example, if the timestamp is down to the second, then multiple message (including replays) could be sent in that second.
the nonce requires some level of persistence, since it only works if uniqueness is guaranteed and checked. Also, if the man in the middle can interrupt the sender, get the nonce, and keep the sender from sending it, the man in the middle attack could still be successful.

转载于:https://www.cnblogs.com/fer-team/p/4331623.html