HTTPSがない場合にJavaScriptを使用してHTTP経由で安全にパスワードを送信する方法
すべての開発者が直面する非常に基本的な問題：ユーザーがフォームを送信するたびに、パスワードはネットワーク経由で送信され、保護する必要があります。私が開発しているサイトにはHTTPSがありません。所有者はSSL証明書を購入することも、自己署名証明書にも興味がありません。そのため、フォームを送信するときにJavascriptを使用してHTTP経由で送信されるパスワードを保護したいと思います。
Downvoterを熱望するために： HTTP経由でパスワードを安全に送信する方法？ 賢明な解決策を提供していません。別の状況にあります。
MD5を使用する場合、そのパスワード文字列を逆にすることができます。 nonce/HMACはどうですか？そのために利用可能なJavascriptライブラリはありますか？または、取り組むべき提案/ヒントはありますか？前もって感謝します！
パスワードを安全に送信する方法はありませんユーザーが確認できる SSLなし。
確かに、ハッシュまたは公開鍵暗号化を介した有線送信のためにパスワードを安全にするJavaScriptを書くことができます。しかし、サイトの代わりに攻撃者にパスワードを送信したり、単にセキュリティを危険にさらしたりするために、ユーザーがJavaScript自体が中間者によって改ざんされていないことをどのようにして確認できますか？アルゴリズム？唯一の方法は、彼らが熟練したプログラマーであり、ページとスクリプトのすべての行を調べて、パスワードを入力する前にそれが正しいかどうかを確認することです。それは現実的なシナリオではありません。
パスワードを中間者攻撃から保護するには、SSL証明書を購入する必要があります。他の方法はありません。それに慣れる。
MD5を使用する場合、そのパスワード文字列を逆にすることができます。
いいえ...少なくとも些細なことではありません。 MD5には攻撃がありますが、ハッシュアルゴリズムであるため、元に戻せません。あなたはそれを総当たりする必要があります。
ただし、中間者攻撃者はMD5を調べる必要はありません。彼は単純にMD5を作成するためにユーザーに送信するJavaScriptを妨害できます。
ここでの解決策は、パスワードをまったく送信しないことです。チャレンジ/レスポンスを使用します。
元のフォームには、キーとともにランダムテキストの大きなブロックが含まれています。サーバー上のキーに基づいて、元のランダムテキストをセッションに保存します。クライアントがフォームを送信したら、JSを使用してランダムテキストとパスワードを一緒にハッシュします。次に、ユーザー名、キー、およびハッシュされたランダムテキストをサーバーに送信します。パスワードを送信しないでください。サーバーで、キーを使用して元のランダムテキストを検索し、保存されたパスワードで同じハッシュ操作を実行します。サーバーのハッシュ値がクライアントのハッシュ値と一致する場合、サーバーにパスワードを送信せずにクライアントが正しいパスワードを入力したことがわかります。
パスワードが正しいかどうかに関係なく、キーとランダムテキストを期限切れにして、それぞれが一度だけ使用されるようにします。
本当にこれを深く掘り下げたい場合は、 Diffie-Hellman key exchange を見てください安全でない通信チャネル」
私は暗号の専門家ではないので、攻撃者がクライアント（JavaScriptソースコード）とトランスポートメカニズム（パケットスニファー）の両方を持っている場合、本当に安全かどうかは完全にはわかりません。
JavaScript RSA実装を使用して、送信前にパスワードを暗号化できます。 （ここに RSA In Javascript の例を示します。）
しかし、私はこれとハッシュ関数の使用の両方が リプレイ攻撃 に対して脆弱であると信じています。ので注意してください。
残念ながら、暗号化されていないリクエストのセキュリティを確保する方法はありません。 javascriptにアクセスできる人は誰でもそれをリバースエンジニアリング/改ざんすることができ、パケットスニファを持っている人は暗号化されていないトラフィックを見ることができます。これら2つの事実は、次のことを意味します。
SSLなし？セキュリティなし
SSLにアクセスできない場合、MD5はパスワード（ネットワークログファイルなど）の偶発的な発見を防ぐのに十分なはずです。それ以外は時間の無駄です。アプリが機密情報（クレジットカード番号、病歴など）にアクセスできないようにしてください。
他のコメント者が示唆したように、深刻な攻撃者はページのあらゆるタイプのセキュリティを破ることができます。ほとんどのユーザーは推測しやすいパスワードを使用し、どこでも同じパスワードを再利用し、尋ねる人にパスワードを与えるか、コピーされたページまたは「技術サポート」の電話。
あなたが持っているすべての送信はクリアになります。つまり、SSLを使用しない場合、重要な情報が公開されます。サイト所有者とその点について議論する価値があります。言い換えれば、データ転送を強化するために必要な措置を講じることが最善であり、SSLはあなたがとることができる基本的で安価なステップの1つです。
ここでの問題はテクノロジーではないと思いますが、SSLの重要性をどのように説明するかです。彼らに信頼できる読み物を提供してください、私はウェブ上にたくさんあると確信しています。
このソリューションでは、クライアントがonlyがクライアントにandであることがわかっている秘密の暗号化キーを使用してパスワードを暗号化できる必要があります。
SSLは、サーバーとクライアントの両方のWebブラウザーに独自の非対称公開/秘密キーペアを要求することでこれを実現します。非対称の公開/秘密キーペアを使用して、ランダムなセッションキーを暗号化および送信します。会話の残りの部分では、その安全なセッションキーが使用されます。
そのため、クライアントとサーバーに既知の秘密鍵onlyを使用することなく、SSLと同じ問題を解決する方法を求めています。私は専門家ではありませんが、これはできない、または少なくとも簡単ではないようです。
前述のように、これはいずれもserverなりすましに対して安全ではありません。これには、クライアント側のJavaScriptを信頼する機能が必要です。しかし、サーバーがスプーフィングできないと確信している場合（署名された証明書、長さ拡張の影響を受けないハッシュ署名など）、not接続が盗聴者の影響を受けないことを、ここに示します。 d実装します。
最も安全な方法は、H（password）を格納する代わりに、Hが選択したハッシュ関数である場合、g ^ H（パスワード）つまり、Diffie-Hellman鍵交換の秘密鍵としてパスワードを使用します。 （おそらく、異なるユーザーにもランダムなgを使用する必要があります。これがソルトになります。）次に、検証するために、ノンスbを生成し、ユーザーg ^ bを送信し、（g ^ H（パスワード））^ b。ユーザーはgを知る必要はありませんg ^ b）^ H（---（password）=（g ^ H（password））^ bを計算するだけです。これで、両方の当事者が知っている数字が得られましたiffユーザーが正しいパスワードを入力し、正しい数字が自明であることに基づいてチャレンジ応答ゼロ知識証明を構築しますが、乱数はサーバーの「秘密鍵」により、このアプローチはリプレイ攻撃の影響を受けなくなります。
-英語-私は何かを考えていますが、本当に安全であるかどうかわかりません。フォームをphpファイルに配置できる場合は、アルゴリズムを作成して、時間または他の何かに基づいて文字列を作成し、この文字列をhtmlに配置できます。
ユーザーがパスワード入力フィールドにパスワードを入力すると、デバッグ時にユーザーが入力した値が表示されないため、postまたはgetを介して情報を送信する前に、暗号化された文字列を暗号化するヒントとしてパスワードユーザーを使用できます生成された後、ユーザーが入力したパスワードの代わりに送信されます。
このように、攻撃者はjsコード内にすべてを持ってはいけないため、解読するために作成したアルゴリズムを発見する必要があります。
これは単なるアイデアであるため、これがどのように安全でないかを教えていただければ幸いです。
-スペイン語-se me acaba de ocurrir algo que puede servir、pero no se si realmente sea algo seguro。アルゴリズムのアルゴリズムを使用して、アルゴリズムのタイムスタンプをアルゴリズムの日付と時刻、アルゴマス、デコロス、コロカ、エスタ、カデナ、その他のHTMLで生成します。
カンポアルギエンを入力し、カンポ入力を禁止し、パスワードを入力し、デバッグし、パスワードを入力しないでください。テクレオの使用法はありません。アシケポドモスユーティリティは、コントラクエを使用します。 como palabra clave para encriptar la cadena de texto que previamente habiamos generado con php、por medio de un algoritmo en JS。 Seríaalgoasícomo encriptar lo encriptado。後部のエスタリアモは、テコンドーラのセリア・ラ・コントラセナにあり、その結果はありません。
Buscando un contra、loúnicoque se me ocurra es que el atacantetendráque dedicarle mucho tiempo para tratar de encontrar el agoritmo que creamos por medio de php y poder decriptar la cadena final、otendráque hackear el servidor para acceder al php y obtenエルアルゴリトモ。
Esto es solo una idea、por lo que si pueden decirme como esto puede no ser seguro、se losagradecería。