**感谢mcfog和yc8332的回答
按照mcfog的回答
如果sign的算法公开的话, sign不就没有校验功能了吗, 恶意攻击的人也可以根据该算法生成sign了**
刚读了一篇相关的博文, 有一点不明, 请大家解惑,谢谢
文中讲到sign是根据用户"请求的所有参数,包括timestamp还有token", 然后通过加密算法生成的sign.
然后他说在验证sign的时候是通过相同的加密规则生成一个sign, 看是否与请求的sign相同.
我的疑惑来了:
用户是怎么知道合法的sign是什么, 是在用户登录成功后, 和token一起返回给客户端的吗?
如果是的话这个token和sign在客户端和服务器端一般是怎么保存的, 是都存放在cookie中和session中?
每次请求的参数和时间戳一定是不同的, 怎么会能"根据用户请求的url参数, 重现出原来加密出的sign", 加密的原始素材只有token没变, 而其他的都变了, 怎么一样呢.
博文的原文如下:
"将所有用户请求的参数按照字母排序(包括timestamp,token),然后根据MD5加密(可以加点盐),全部大写,生成sign签名,这就是所说的url签名算法。然后登陆后每次调用用户信息时,带上sign,timestamp,token参数。"
"根据用户请求的url参数,服务器端按照同样的规则生成sign签名,对比签名看是否相等,相等则放行。(自然url签名也无法100%保证其安全,也可以通过公钥AES对数据和url加密,但这样如果无法确保公钥丢失,所以签名只是很大程度上保证安全)"
로그인은 저장되지 않고 동적이며 제출된 매개변수에 따라 암호화됩니다. 주로 중간자 공격이나 데이터 무결성을 방지하는 데 사용됩니다.
1. 부호의 알고리즘은 서버에 의해 공개됩니다. 클라이언트는 요청할 때마다 부호를 스스로 계산합니다.
2. 계산될 때마다 서명합니다. 컨텍스트가 부족하고 그것이 무엇인지에 대한 설명이 없습니다. 다음 두 가지일 수 있습니다
공격자가 요청을 변조/위조하는 것을 방지하기 위해 일반적으로 서명 요소에는 공격자가 획득하기 어려운 요소가 하나 이상 포함되어 있습니다. 가장 일반적인 요소는 양측이 합의한 비밀입니다.
재생 공격을 방지하려면 데이터 패킷에 고유한 요청 시퀀스 번호/밀리초 시간 및 기타 유형의 요소를 포함하고 서버 측에서 중복 제거 처리를 수행하는 것이 가장 좋습니다
3, 서버가 요청을 받은 후 처리 방법을 설명합니다. 부호 알고리즘을 사용하여 수신된 요청의 다양한 매개변수를 통해 부호 값을 계산하고 이를 클라이언트가 제출한 부호 값과 비교합니다. 클라이언트가 올바르게 계산했습니다.
제안: 제목 책에서는 너무 많이 읽었고 너무 적게 수행했습니다. 특히 OAuth와 같은 여러 실제 API 인터페이스에 연결하면 기본적으로 이러한 내용을 이해할 수 있습니다.
공개란 자신의 사람들에게 공개하는 것을 의미합니다. 이것을 걱정하고 싶다면 세상에 안전한 것은 없습니다. 처리도 안 돼요