この記事では、PHPを使用したサイトでの承認のアイデアを説明することにしました。
もちろん、SSLで認証が行われた場合、スニファーを使用してパスワードが傍受されるリスクは無効になります。 それでも、このタイプの認証は常に使用されるとは限りません。 保護の1つのタイプは、ハッシュ形式のパスワードのコンテンツです。 ただし、認証後、パスワードはPOSTリクエストでサーバーに送信され、パスワードをキャッチする可能性があります。 熟考した上で、パスワードがその形式でサーバーに送信されない認証スキームの実装を試みることにしました。 そして彼のMD5ハッシュでさえありません。 計画には、ms-chapアルゴリズムに似たものがありました。
すなわち：
1）サイトにアクセスすると、Cookie内の許可されていないユーザーに一意のIDが付与されます。
2）ユーザーがログインすることを決定した場合、パスワードを入力するときに、パスワードのmd5ハッシュとサーバー側からユーザーに発行されたIDに基づいてハッシュが生成されます。
3）許可の試行後、その結果に関係なく、idは上書きされます。
結果として何が得られますか？ 許可が試行されるたびに、前のハッシュとは異なる新しいハッシュが生成され、それをキャッチしても意味がありません。
それでは始めましょう：
この記事は既製のコードを意味するものではなく、アルゴリズムとロジックに焦点を当てているため、このロジックの実装のベースとなる低音の瞬間のみが示されています。 ここでの本質はアルゴリズムにあり、誰もが独自の方法で環境を構築します。
そのため、サイトのルートでは、ユーザーは「ソルト」を割り当てられます。これは、最初と各認証試行の後に生成されます。
session_start();
さらにログインの形式で：
<form action="" method="post">
どうすれば絶えず変化するパスワードを取得するのか、どうすればそれをどう処理するのかがわかりません。
フォームを送信した後、ログインとパスワードをチェックする機能に入ります。 ここでも、味と色のマーカーが異なります。 私の場合、フォームの代わりに、ページが更新された結果の後に承認関数が呼び出され、承認が成功した場合、ワークスペースに入ります。 結果が失敗した場合は、再度エントリフォームを確認します。
function CheckLogin($login,$md5pass) {
UPD：この記事では、コード自体を前提としていませんでしたが、実装のアルゴリズムは誰もが異なると見なしています。 また、「穴がコピーされ、一般的に耕されていない」というトピックに関するホリバーの離婚のためではなく、ブラケットが曲がっています。 しかし、すべてのコメントがそれに反発したため、猫を削除する必要がありました。これは原始的であり、非命令に対するアクションを意味していました。