SSLを使用せずにログインページを安全にするテクニック
私は、人々が物事を書いてコメントできる（個人情報は必要ありません）Webページを開発しています。ユーザーが私のWebページですべてのアクションを確認できるように、フォームをログに記録する必要があります。私の考えは、SSLを使用せずにログインフォームをプログラムし、必要に応じてFacebookでログインできるようにすることです。 JavaScriptが有効になっている場合のみ、ページが完全に読み込まれます。
私の最初の問題は、真ん中の男のように振る舞うことによって誰もユーザーの資格情報を盗むことができないことを確認することです。 JavaScriptを使用してクライアント側で最初のハッシュ、次にサーバー側でそれを解決することを考えました。ハッシュ値を受け取った場合（誰かがJavaScriptを削除した場合）、2番目のハッシュを実行し、それらのハッシュ値をユーザーデータベースに格納します。それを実装する安全な方法ですか？また、一部のデータが失われる可能性はありますか？もしそうなら、受信したデータが危険にさらされていないかどうかはどうすればわかりますか？
辞書やブルートフォース攻撃から保護します。そのユーザーアカウントに関連付けられている失敗したログイン試行の数を数えることで解決します。それが8〜10行を超える場合は、次のログインごとにCAPTCHAを表示し、連続するログイン試行間の時間遅延も実装します。サーバー側で失敗したログインの数を数えているので、IPの変更は問題にならないと思います（PHPでユーザー変数を設定します）。
ログインフォーム。私はそれをこのように実装しました（今のところハッシュなし）：
<input id="username" name="userName" placeholder="Username" type="text"> <input id="password" name="pass" placeholder="Password" type="password">しかし、フォームがURLで送信されると、次のようなパスワードを読み取ることができます。/LogIn.php?userName=user&pass=passパスワードを非表示にするにはどうすればよいですか？
SSLを使用せずに最大限のセキュリティを実現するために、他にどのようなアドバイスがありますか？
TLSの使用を拒否するのはなぜですか？それは動作します、それは良い実績があります（いくつかのマイナーな例外は別として）。説得力のある理由なしに優れたツールを使用することを拒否することは、自信を生むことはなく、すぐにプロ意識を示唆するものではありません。
また、独自の認証システムを導入しないでください。それはばかげている、そしてあなたは間違いをするでしょう。代わりに、ユーザーがFacebookアカウントを持っていることを想定しているため、OAuth2を使用してフェデレーションIDと認証を利用します。さらに、これをマスターし、コードスニペットを提供するフェデレーションサービスにこれを外部委託します（ https://oauth.io/ が思い浮かびます）。
あなたの人生を困難にしないでください。
SSL/TLS証明書は2015年の第2四半期までに無料になります。ここで証明書を取得します。
Let's Encryptは、ドメインで検証された証明書 IdenTrustを通じて署名 を無料で提供します。
これが公開されると、これらの質問は終了する必要があります。
SSLを使用せずに最大限のセキュリティを実現するために、他にどのようなアドバイスがありますか？
愚かなことをする代わりにTLSを使うことができます。
TLSなどのファイルをクライアントに安全に送信する方法がないと、実行しようとしていることは不可能です。パスワードをクライアント側でハッシュするアプローチでは、JavaScriptをクライアントに安全に送信する必要があります。それ以外の場合、MITMはnotをハッシュするスクリプトを提供するだけで、代わりにクリアテキストのパスワードを直接送信できます。
重要な部分は、クライアントの信頼できるコードが必要であることです。 TLSでは、その信頼できるコードはブラウザーであり、ブラウザーはJavaScriptの整合性を検証して、JavaScriptも信頼できるようにします。これまたは同等の機能（私にはわかりません）に依存しないと、クライアントのマシンで何が実行されているかを推測することはできません。
TLSなしで安全を確保する唯一の方法は、ブラウザのプラグインで、TLS経由でダウンロードする必要があります。また、ブラウザプラグインは、ユーザビリティの大きな欠点です。
これは、ユーザーのコンピューターに信頼できるコードが必要なためです。これは、ユーザーのブラウザーのTLSコードまたはプラグインコードのいずれかです。
実際にIS SSLより前の「安全な」認証方式と呼ばれる デジタルアクセス認証 があるため、質問者が尋ねていることはまったく不可能ではありません。これはFARはSSLよりも安全性が低く、オフライン攻撃によってパスワードをブルートフォースで強制し、MD5の古い、信頼性の低いハッシュアルゴリズムを使用する可能性があります。
私は他の人と同じアドバイスをしますが、SSLは1993年以降更新されていない古いチャレンジ/レスポンスベースのシステムに依存するよりもはるかに優れたソリューションです。
他の答えは明らかです-SSLを使用してください
ただし、説明どおりに実装した場合に何が失敗するかを指摘するには、次のようにします。
JavaScriptを使用してクライアント側で最初のハッシュ、次にサーバー側でそれを解決することを考えました。ハッシュ値を受け取った場合（誰かがJavaScriptを削除した場合）、2番目のハッシュを実行し、それらのハッシュ値をユーザーデータベースに格納します。それを実装する安全な方法ですか？また、一部のデータが失われる可能性はありますか？もしそうなら、受信したデータが危険にさらされていないかどうかはどうすればわかりますか？
したがって、このシナリオでは、MITMはクライアントから送信されたハッシュを受信します。これがログインなどの場合、コピーして、Xとしてログインするたびに送信できます。データが失われる可能性はありますか？ MITMでは、一部のデータが失われる可能性があることが基本的に保証されています。問題は、それを検出できるかどうかです。受信したデータが危険にさらされていないことをどのようにして知ることができるかについては、典型的な方法はそれに署名することです。
SSLを使用する必要がない場合は、代わりに WS Security を使用して安全にSSLをプルオフできますが、SSLよりも複雑になるので注意してください。
辞書やブルートフォース攻撃から保護します。
一般的に、あなたが説明したようにそれらを打ち負かすことができますが、ブルートフォース攻撃を本当に心配する必要があるのはオフライン攻撃です-つまり、コードが実行されておらず、ログイン試行の頻度を制限することによってデータを保護できない場合-多くのラウンドそれを行うにはハッシュが必要です
ログインフォーム。私はこの方法で実装しました（今のところハッシュなし）
攻撃者が同じデータのハッシュ化されたURLまたはハッシュ化されたペイロードを表示した場合、正確にはどのような違いがありますか？とにかく、URLのデータが必要ない場合は、HTTP GETの代わりにHTTP POSTを使用してください。