java - 关于"api接口的sign的设计"的一点点疑惑

Question

**感谢mcfog和yc8332的回答
按照mcfog的回答
如果sign的算法公开的话, sign不就没有校验功能了吗, 恶意攻击的人也可以根据该算法生成sign了**

刚读了一篇相关的博文, 有一点不明, 请大家解惑,谢谢

文中讲到sign是根据用户"请求的所有参数,包括timestamp还有token", 然后通过加密算法生成的sign.
然后他说在验证sign的时候是通过相同的加密规则生成一个sign, 看是否与请求的sign相同.

我的疑惑来了:

1. 用户是怎么知道合法的sign是什么, 是在用户登录成功后, 和token一起返回给客户端的吗?

2. 如果是的话这个token和sign在客户端和服务器端一般是怎么保存的, 是都存放在cookie中和session中?

3. 每次请求的参数和时间戳一定是不同的, 怎么会能"根据用户请求的url参数, 重现出原来加密出的sign", 加密的原始素材只有token没变, 而其他的都变了, 怎么一样呢.

博文的原文如下:

"将所有用户请求的参数按照字母排序（包括timestamp，token），然后根据MD5加密（可以加点盐），全部大写，生成sign签名，这就是所说的url签名算法。然后登陆后每次调用用户信息时，带上sign，timestamp，token参数。"

"根据用户请求的url参数，服务器端按照同样的规则生成sign签名，对比签名看是否相等，相等则放行。（自然url签名也无法100%保证其安全，也可以通过公钥AES对数据和url加密，但这样如果无法确保公钥丢失，所以签名只是很大程度上保证安全）"

Answer 1

署名は保存されず、動的であり、送信されたパラメータに基づいて暗号化されます。主に中間者攻撃やデータの整合性を防ぐために使用されます。

Answer 2

1. 符号のアルゴリズムはサーバーによって公開されます。クライアントはリクエストを行うたびに符号を計算します。
2.トークンを計算するたびに署名します。コンテキストが不十分で、それが何であるかについての説明がありません。それは以下の2つかもしれません

1. 一般に「シークレット」として知られる、サーバーからクライアントに発行されるプライベート文字列。クライアントは、この文字列を漏洩から保護し、クライアントの法的身元を確認するたびにこの文字列を使用して署名に参加する必要があります。通常、クライアントは構成内に配置され、サーバーには通常、さまざまなクライアントのシークレット値を維持するためのデータベースがあります

2. 一般に「アクセス トークン」として知られ、ログイン インターフェイス リクエストを通じてクライアントによって取得されるセッション ID に似た文字列で、ログイン ステータスを表します

攻撃者によるリクエストの改ざん/偽造を防ぐために、署名の要素には通常、攻撃者が取得するのが困難な要素が少なくとも 1 つ含まれます。最も一般的なのは、双方が合意した秘密です。

リプレイ攻撃を防ぐには、データパケットに固有のリクエストシーケンス番号/ミリ秒時間やその他の種類の要素を含め、サーバー側で重複排除処理を実行するのが最善です

3、これは、サーバーがリクエストを受信した後の処理方法を説明します。これは、受信したリクエスト内のさまざまなパラメータを通じて符号アルゴリズムを使用して符号値を計算し、それをクライアントによって送信された符号値と比較します。クライアントは正しく計算しました。

提案: タイトルの本を読みすぎましたが、実際の API インターフェイス、特に OAuth に接続してください。

Answer 3

公開とは、自分自身の人々に公開することを意味します。これについて心配したい場合、世界に安全なものはありません。加工も出来ません