API 設計 - PHP インターフェイスのトークン データ暗号化

最近 php を使用してアプリのインターフェイスを作成しているのですが、いくつか質問があります

まずはトークンについて
トークンはユーザーがログインすると生成されます
ユーザートークンはサーバーに保存され、クライアント上でローカルにキャッシュされます。ほとんどのインターフェイスでは、クライアントがトークンを送信し、検証のためにサーバーデータベースにトークンを保存する必要があります。

各ユーザーの一意のトークンは、年と月、およびユーザー ID を識別するためのクライアント マシン コードで構成されます
(年と月は、ユーザーが次回ログインしたときに確実にログインできるようにするためのログイン保持期間に使用されるマシン コードです)ログイン元をすぐに特定して、再度ログインする必要がある重要な認証情報であるかどうかを判断できます。ちなみにユーザー ID は実際に追加されます)

ここで質問です
=。 = これはセッションと何ら変わりません
**パッケージを直接キャプチャした場合
プラットフォームのクライアント上のすべてのユーザーのトークンは同じであり、攻撃の防止には役に立ちません**
そしてこの種のトークンはベースになっていますこの種のトークンは、ユーザーのログインおよび登録検証 (ロボット対策) 検証には役立ちません
=。 =私はまだ検証するものを設計中です (このトークンのアイデアに基づいてログインと登録の検証も行う方法はありますか)

返信内容:

最近 php を使用してアプリのインターフェイスを作成しているのですが、いくつか質問があります

まずはトークンについて
トークンはユーザーがログインすると生成されます
ユーザートークンはサーバーに保存され、クライアント上でローカルにキャッシュされます。ほとんどのインターフェイスでは、クライアントがトークンを送信し、検証のためにサーバーデータベースにトークンを保存する必要があります。

各ユーザーの一意のトークンは、年と月、およびユーザー ID を識別するためのクライアント マシン コードで構成されます
(年と月は、ユーザーが次回ログインしたときに確実にログインできるようにするためのログイン保持期間に使用されるマシン コードです)ログイン元をすぐに特定して、再度ログインする必要がある重要な認証情報であるかどうかを判断できます。ちなみにユーザー ID は実際に追加されます)

ここで質問です
=。 = これはセッションと何ら変わりません
**パッケージを直接キャプチャした場合
プラットフォームのクライアント上のすべてのユーザーのトークンは同じであり、攻撃の防止には役に立ちません**
そしてこの種のトークンはベースになっていますon この種のトークンは、ユーザーのログインおよび登録検証 (ロボット対策) 検証には役立ちません
=。 =私はまだ検証するものを設計中です (このトークンのアイデアに基づいてログインと登録の検証も行う方法はありますか)

この質問は非常に簡単で、例として PHP を使用しています。
しかし、これは session不一样，和cookies に少し近いもので、面倒な Cookie 値の転送の問題を解決するために設計されています。

---

まず第一に、ログインプロセス中に、ユーザーはサーバーにデータを送信します。これには、
username、password、username、password、client_key
php在服务端拿到这些数据之后，用校验算法获取校验值，如md5。
(ps:不加密码是不行的，否则用户修改密码后之前的还是可以快捷登陆，这不坑人吗)
$salt是一个加密key

PHP がサーバー上でこれらのデータを取得した後、検証を使用します。アルゴリズムは、md5 などのチェック値を取得します。

(追記: パスワードがないと不可能です。そうでない場合、ユーザーはパスワードを変更してもすぐにログインできます。これは詐欺ではないでしょうか?)$token返回到客户端，作为存储。以后客户端只需要向服务端发送此$token$salt は 暗号化キー 、他の人が暗号化アルゴリズムを推測できないようにします。

リーリー

計算が完了すると、$tokenとユーザー名が追加されます。

---

phpがこれを受け取ると

、一貫性があるかどうかを確認するために上記の操作を再度実行しますので、すぐに判断できます。 client_key 悪意のある登録とログインを防ぐ必要がある場合は、クライアントで暗号化してから、検証のためにサーバーで復号化する必要があります。ただし、これは役に立ちません。
すべてのクライアント コードは安全ではないため、逆コンパイルすることができます。難読化防止機能を使用して、通常どおり偽装します。
したがって、クライアント側での暗号化は意味がありません。

さらに、IPでサーバーを判断するのも一つの方法です。

ただし、基本的には悪意のある攻撃を防ぐため、登録前に携帯電話番号を認証する必要があり、現在は基本的にこの方法で実現されています。

私も書いていますが、まだ実装されていません

1. ユーザーがトークン検証 (アプリ上の Cookie に似たもの) を通じてログインする場合、ユーザーはそれを使用してログインすることに問題はありません。ユーザーが別のクライアントからログインする場合、ユーザーは次のことを行う必要があります。再度ログインし、検証中に実行します。クライアントのマシンコードを取得して一致させます。

🎜さらに、クライアントのトークンは、js を使用して暗号化され、php で取得されて解析される複雑な場合もあります。

トークンはある程度安全ではありませんが、ユーザーのパスワードを渡すよりは安全です。
トークンを使用するシナリオは、通常、ステートレスで Cookie を使用しないモードです。トークンがある場合、それは Cookie 内のセッション ID として機能します。
トークンは安全ではありませんが、ある程度の検証モードを使用すれば信頼できます

少し前にブログを書いたばかりですが、技術的な詳細は含まれていませんでしたが、参考になるか見てみましょう。

まず第一に、Token是用于登录后验证身份的，所以一开始就否决了你期待用它来做防恶意注册，这两者完全不搭嘎。其次，要说Token与Session有什么区别，那区别就在于Token更具有定制型，因为它是由你实现的，就能干很多Session不方便干的事情，比如更好的做设备认证，更方便的控制有效期，更好的跨平台性……最重要的，HTTP协议本身定义就是无状态的，而Cookie这种东西的存在无疑有损无状态这个定义，所以几乎所有的接口都拒绝使用Cookie，弃了Cookie，那Token自然成了验证的首选。最后，Token のセキュリティは、送信中に傍受されて中間者攻撃を引き起こすかどうかではなく、クラックされたり改ざんされたりするかどうかに焦点を当てていることを明確にしておく必要があります。傍受保護は、パラメータ署名の追加や HTTPS の直接使用など、送信プロセス中のセキュリティを強化することによって実現する必要があります。