javascript - SSL を使用しない双方向パスワード暗号化

Question

Twitter をブログのコメントシステムと統合するために、basic-auth Twitter API (使用できなくなりました) を使用しています。この Web API や他の多くの Web API の問題は、有用なことを行うためにユーザーのユーザー名とパスワードが必要になることです。SSL 証明書をインストールする手間とコストに対処したくありませんが、ネットワーク上でパスワードがクリアテキストで渡されることも望ましくありません。

私の一般的な質問は次のとおりだと思います:安全でないチャネルを介して機密データを送信するにはどうすればよいですか?

これが私の現在の解決策であり、穴があるかどうかを知りたいです:

サーバーでランダムなキーを生成します (私は php を使用しています)。
キーをセッションに保存し、キーを javascript 変数に出力します。
フォームの送信時に、javascript でトリプル DESとキーを使用してパスワードを暗号化します。
サーバーで、セッションのキーを使用してパスワードを復号化し、セッションを破棄します。

最終的には、暗号化されたパスワードのみがネットワーク経由で送信され、キーは 1 回だけ使用され、パスワードと共に送信されることはありません。問題が解決しました？

score 34 · Accepted Answer

サーバーでランダムなキーを生成します (私は php を使用しています)。

キーをセッションに保存し、キーを javascript 変数に出力します。

フォームの送信時に、javascript でトリプル DES とキーを使用してパスワードを暗号化します。

これにより、暗号化されていないパスワードをネットワーク上で送信することは回避されますが、暗号化されていないキーをネットワーク上で送信する必要があり、誰でも盗聴してパスワードを解読することができます。

以前にも言われましたが、もう一度言います。独自の暗号化プロトコルを作成しようとしないでください。専門家によって作成され、ピアレビューされ、打ちのめされ、ハッキングされ、突かれ、突きつけられた、この種の確立されたプロトコルがそこにあります。それらを使用してください! 暗号化とセキュリティのコミュニティ全体が協力するよりも優れたものを思いつくことができる人は誰もいないでしょう.

score 10 · Accepted Answer

あなたの方法には欠陥があります-誰かがユーザーへのキーの送信とユーザーの暗号化された返信を傍受した場合、返信を解読してユーザーのユーザー名/パスワードを取得できます。

ただし、 Diffie-Hellman アルゴリズムとして知られている、転送中に情報が変更されない限り、安全でない媒体を介して情報を安全に送信する方法があります。基本的に、2 者は会話に基づいてデータの暗号化に使用される共有鍵を計算できますが、オブザーバーには鍵を推測するのに十分な情報がありません。

ただし、クライアントとサーバー間の通信を設定するのは難しい場合があり、単純に SSL をサイトに適用するよりもはるかに時間がかかります。料金を支払う必要さえありません。必要な暗号化を提供する自己署名証明書を生成できます。これは中間者攻撃から保護しませんが、Diffie-Hellman アルゴリズムも保護しません。

score 6 · Accepted Answer

サーバーに証明書を持っている必要はありません。認証されていないサーバーと通信するかどうかは、クライアント次第です。プライベートチャネルを確立するために、引き続きキーの合意を実行できます。ただし、認証されていないサーバーにプライベート資格情報を送信するのは安全ではありません。そのため、SSL が実際にこのように使用されることはありません。

一般的な質問に答えるには、送信するだけです。あなたの本当の一般的な質問は、「安全でないチャネルを介して機密データを送信し、安全に保つにはどうすればよいですか?」ということだと思います。 できません。

証明書にかかる月額 10 ～ 20 ドルのセキュリティは価値がないと判断したようですね。Twitter のパスワードを保護するには、おそらくその通りです。では、セキュリティの幻想を提供するために時間を費やす必要はありません。パスワードが平文で送信されることをユーザーに明確にし、ユーザーが自分で選択できるようにしてください。

score 2 · Accepted Answer

API と OAuth

まず、他の人が言ったように、ユーザーのパスワードを使用して API にアクセスするべきではなく、OAuth トークンを取得する必要があります。これにより、パスワードを必要とせずに、そのユーザーに代わって行動できるようになります。これは、多くの API で使用される一般的なアプローチです。

鍵交換

安全でない接続を介して情報を交換するというより一般的な問題を解決する必要がある場合は、他の回答で言及されているように、いくつかの鍵交換プロトコルがあります。

一般に、鍵交換アルゴリズムは盗聴者から保護されていますが、ユーザーの ID を認証しないため、中間者攻撃に対して脆弱です。

Diffie Hellmanのウィキペディアのページから:

元の説明では、Diffie-Hellman 交換自体は通信当事者の認証を提供しないため、中間者攻撃に対して脆弱です。中間の人物が 2 つの異なる Diffie-Hellman 鍵交換を確立する可能性があります。1 つは Alice と、もう 1 つは Bob との鍵交換です。事実上、Alice から Bob になりすまし、逆の場合も同様であり、攻撃者が復号化 (および読み取りまたは保存) してから再暗号化できるようにします。彼らの間で交わされたメッセージ。この種の攻撃を防ぐには、通常、通信する当事者を相互に認証する方法が必要です。STSなどの Diffie-Hellman のバリアントを代わりに使用して、これらのタイプの攻撃を回避できます。

攻撃者が送信者または受信者の代わりに自分の ID (署名キー) を挿入できる場合、STS でさえ安全ではありません。

ID と認証

これはまさに、SSL が解決するように設計された問題です。理論的にはドメイン名の所有者などを検証した「信頼できる」署名機関の階層を確立することにより、Web サイトに接続している誰かが、実際にそのドメインのサーバーと通信していることを確認できます。、そして間に挟まれた中間者ではありません。

接続を暗号化するために必要な構成を提供する自己署名証明書を作成できますが、認証されていない Diffie-Hellman 鍵交換が保護しないのと同じ理由で、中間者攻撃から保護することはできません。

https://www.startssl.com/から 1 年間有効な無料の SSL 証明書を取得できます- 私は個人サイトに使用しています。彼らは、申請した人を自動的にチェックするだけなので、それが意味するものは何でも「信頼できる」とは言えませんが、無料です. 費用がほとんどかからないサービスもあります (英国の 123-Reg からは年間 10 ポンド)。

score 2 · Accepted Answer

では、これはどのようにしてより安全になるのでしょうか? ブラウザ<>サーバーを保護したとしても、残りのインターネット (サーバー<>twitter) はどうでしょうか?

私見ですが、別のサービスのユーザー名とパスワードを要求し、人々がそれを入力することを期待することは受け入れられません。そして、あなたがそんなに気にするなら、彼らが彼らの行動を正して OAuthを再び有効にするまで、それらを統合しないでください。(しばらくはサポートしていましたが、数か月前に無効にしました。)

それまでの間、なぜ OpenID を提供しないのですか? すべての Google、Yahoo!、VOX などのアカウントには 1 つのアカウントがあります。人々は気付いていないかもしれませんが、すでに OpenID を持っている可能性は非常に高いです。このリストをチェックして、私が何を意味するかを確認してください。

score 2 · Accepted Answer

キーがクライアントとサーバー間で送信されるとき、それはクリアテキストであり、傍受される可能性があります。それをパスワードの暗号化されたテキストと組み合わせると、パスワードが復号化されます。

Diffie-Hellmanは優れたソリューションです。それらを認証する必要があるだけで、実際にパスワードを送信しない場合 (パスワードは既にサーバーに保存されているため)、HTTP Digest Authentication、またはそのバリエーションを使用できます。

score 1 · Accepted Answer

別のアプローチを実装しました

サーバー：データベースに保存されているユーザー名とパスワードのハッシュ
サーバー：フォームを使用してチャレンジを送信し、パスワードを要求し、タイムスタンプとクライアントのIPアドレスを使用してセッションに保存します
クライアント：パスワードをハッシュし、challenge | username | passwordhashを連結し、再度ハッシュしてサーバーに投稿します
サーバー：タイムスタンプ、IPを確認し、同じ連結/ハッシュを実行して比較します

これはパスワード送信に適用されます。データに使用するということは、プレーンテキストの暗号化キーとして最終ハッシュを使用し、暗号文とともにサーバーに送信されるランダムな初期化ベクトルを生成することを意味します。

これについて何かコメントはありますか？

score 1 · Accepted Answer

クライアント側の JavaScript セキュリティの問題は、攻撃者が転送中の JavaScript を単純な {return input;} に変更できるため、手の込んだセキュリティが無意味になることです。解決策: ブラウザー提供の (つまり、送信されない) RSA を使用します。私の知る限り、まだ利用できません。

score 0 · Accepted Answer

安全でないチャネルを介して機密データを送信するにはどうすればよいですか

事前共有秘密鍵を使用。これは、提案されたソリューションで試みたものですが、安全でないチャネルを介してそのキーを送信することはできません。キーのネゴシエーションに役立つ DH について誰かが言及しました。しかし、SSL が行うことのもう 1 つの部分は認証を提供することです。中間者攻撃を防ぎ、クライアントが通信相手とキーをネゴシエートしていることを認識できるようにします。

Chris Upchurch のアドバイスは、エンジニアの 99.99% にとって本当に唯一の良い答えです。実行しないでください。他の誰かにそれをやってもらい、そのソリューションを使用してもらいます (SSL クライアント/サーバーを書いた人など)。

ここでの理想的な解決策は、Twitter に OpenID をサポートしてもらい、それを使用することだと思います。

score 0 · Accepted Answer

オリへ

たとえば、あなたのアプローチでは、私は同じルーターで同じサブネットにいるので、仕事の同僚と同じ IP を取得します。ブラウザーで同じ URL を開くと、サーバーは同じ IP でタイムスタンプを生成し、tcp/ip ダンプを使用して、同僚の接続からハッシュ化されたパスワードまたはハッシュ化されていないパスワードを盗聴します。私は彼が送信するすべてを嗅ぐことができます。だから私は彼のフォームからのすべてのハッシュを持っています。また、あなたはタイムスタンプ（私の）と同じIPを持っています。それで、投稿ツールを使用してすべてを送信し、ログインしました.

score 0 · Accepted Answer

自己署名の SSL 証明書には費用がかかりません。無料の Twitter サービスの場合、それはおそらくユーザーにとっては問題ありません。

score 0 · Accepted Answer

同様の問題（ssl証明書にお金を払わずにフォームでデータを暗号化したい）があるので、いくつか探してみて、このプロジェクトを見つけました：http://www.jcryption.org/

私はまだそれを使用していませんが、実装するのは簡単に見えます.

score 0 · Accepted Answer

SSL を使用したくない場合は、kerberos などの他のプロトコルを試してみませんか?

基本的な概要はこちら: http://www.kerberos.org/software/tutorial.html

または、もう少し詳しく知りたい場合は、 http://www.hitmill.com/computers/kerberos.htmlを参照してください。

javascript - SSL を使用しない双方向パスワード暗号化

13 に答える 13

Related

Reference