【ASP.NET】パスワードを平文で送信したくない

Question

ASP.NET（VB2008）でWebサイトを作成しています。

社内のイントラネットで使用するシステムです。

ログオン画面を作成しているのですが、
パスワードを平文でネットワーク上に送信したくないという要望があります。

調べてみるとSSLという技術があり、
これを使えばパスワードが暗号化されることが分かったのですが
証明書を購入しなければならないようですので、
費用と証明書を更新しなければならない保守作業が発生する面から避けたいと思っております。
（イントラ環境でしか使われないので、無料の無限に有効な証明書を使えればよいのですが。。。）

そこでその他の方法はないだろうかと思い質問させて頂きました。

制約としては、クライアントの端末には何もインストールさせたくありません。
クライアント端末はWindows 2000、XPでサーバーはWindows Server 2003です。

何か良い方法がございましたら、
教えて頂けませんか？
ASP.NET以外のJavaScript等の技術を使っても構いません。

ぜひよろしくお願い致します。

Answer 1

調べてみるとSSLという技術があり、
これを使えばパスワードが暗号化されることが分かったのですが
証明書を購入しなければならないようですので、
費用と証明書を更新しなければならない保守作業が発生する面から避けたいと思っております。
（イントラ環境でしか使われないので、無料の無限に有効な証明書を使えればよいのですが。。。）

安易にオレオレ証明書を使う人が多いです。無料で無期限に有効な証明書ですが、暗号化した気分になれる だけであり、実際には盗聴されていても気付かれることはまずありません。

現状、ID/Passwordはどうしているのでしょうか？
Windowsアカウントを作り、Windows認証プロバイダ を使用すると平文で送信しなくなります。

Answer 2

社内のイントラネットなら、Windows Server 2003 とか 2008 を導入し、Active Directory アカウントをユーザーに持
たせ、統合 Windows 認証を利用するということになると思います。その他の方法は思いつきません。

ちょっと古い記事ですが、以下のページを読んでみてください。

ASP.NET における認証 : .NET セキュリティ ガイド
http://msdn.microsoft.com/ja-jp/library/ms978378.aspx

Answer 3

現状の構成を極力踏襲するとすれば、https (SSL) で通信するように構成するのが一番です。

社内なら独自証明書を発行して利用すれば無料利用できます。

---

http://blogs.wankuma.com/hatsune/

Answer 4

それをやると「実際には盗聴されていても気付かれることはまずありません。」という問題点を既に指摘しているんですが。

Answer 5

>それをやると「実際には盗聴されていても気付かれることはまずありません。」という問題点を既に指摘しているんですが。

すいません、盗聴をどういう意味で使ってますか？
自分の認識ではたとえオレオレ証明を使っても盗聴はされないと認識してますけど。

SSLを利用する上でオレオレ証明を使う問題はAからBへの通信の開始時に相手がBである事が正しいという検証ができないだけで、AとB(かもしれないだれか）で確立されたセッション上で流れているデータは盗聴できないはずです。

---

Kazuhiko Kikuchi

Answer 6

外池と申します。過去に、Windows ServerのCertificate Server（と言うんでしたっけ？）で独自に証明書を発行して、イントラのみならず、外部からのアクセスも含めて運用したことがあります。このとき、いろいろ議論・勉強して得た知識から、私としては、以下のように整理しています。

1) SSL通信のhttpｓの場合、ある特定のクライアントがある特定のサーバーと通信を行っている事実は、通信経路上で「盗聴」することによって知ることができます。

2) しかし「盗聴」しても、クライアントからどのような要求が出ているか、サーバーからどのような応答があったかは、すべて暗号化されているので、とりあえず中身はわかりません。これには、ユーザー名やパスワードなどの認証情報も含まれます。

3) 「オレオレ証明書」を使ってSSL通信を行うサーバーについて、そのサーバーの実在性の証明ができません。サーバーにアクセスするクライアントから見て、そのサーバーが「本物か、偽者か」の判断が出来ないことになります。ただ、サーバーの「成りすまし」を心配する必要がなければ、このことは心配しなくていいでしょう。

4) オフラインで「オレオレ証明書」を配布できるルート（オンラインでもいいんですが、要するに、実在性が問題となるサーバーを使わないルート。）があれば、管理者からクライアントに事前に証明書を配布して、ブラウザに組み込んでおけば、3)で心配になる「成りすまし」も防げます。つまりですね、「社長」が「オレオレ証明書」を「手渡し」してくれるなら信頼できるわけです。この配布の手間だけは必要です。

5) この配布をオンラインで行い、その配布行為の信頼性を第三者機関が面倒を見てくれるのが、「本物証明書」の便利なところです。

そんなわけで、私から申し上げる結論は、イントラネットであれば「オレオレ証明書」で十分です。

「本物証明書」は、商取り引きに代表されるように、特定のサーバーが不特定多数のクライアントに対して実在性を証明する場合に必要なものと言えます。

---

（ホームページを再開しました）

Answer 7

それをやると「実際には盗聴されていても気付かれることはまずありません。」という問題点を既に指摘しているんですが。

独自証明書（オレオレ証明）だと盗聴されていても（そして文脈からすれば内容も解読されちゃう？）気付かれる事はない、（ということはこれまた文脈からすれば）ちゃんと証明書をとればそんな事はないという根拠が判りません。

それとも、盗聴というよりサーバーなりすましという事ですか？

追記:

社内イントラネットじゃなくて公開サーバーとかだったら、オレオレ証明書つかうとかは問題です。

---

http://blogs.wankuma.com/hatsune/

Answer 8

セッションが確立してからの盗聴は難しいですが、「AからBへの通信の開始時に相手がBである事が正しいという検証ができない」ために、AがAでなくてもBからはわかりません。

AとBとが証明書aを使用し暗号通信するとします。ところがAとBの間には最初から中継者Cがいたとします。中継者CはAとは証明書aを使って復号し盗聴します。更に証明書cを使ってBと暗号通信します。Bから見て、証明書aも証明書cもオレオレ証明書でありどちらが本物かわかりません。
これをman-in-the-middle attack というそうです。

そのため、SSLを使用するならば信頼された証明書（どこかから購入したり、外池さんの書かれている4)を実施したもの）が必要です。

初音玲さん：
この方法だと内容も解読できるため暗号の意味をなさないです。目的が盗聴で手段がなりすましです。

外池さん：
外池さんのように説明できる方なら問題ないと思います。しかし、kazukさんや初音玲さんのようにどのように盗聴されるのか理解されていない方が多いことがオレオレ証明書の問題点だと思います。

Answer 9

なりすましと説明せずに盗聴されると書いても意図が伝わらないですよ。
少なくともなりすまされちゃったら盗聴以前の話のようなイメージがありましたから。

でもあれか、社内イントラネットとはいえ悪意ある社員が何か仕掛ける可能性があるので、httpじゃなくてhttpsにしたいって要望があるならきちんとした認証局からの証明書でやった方がいいってことですよね。
自分の知識かきかえておきます！

追記：
ところで、なりすましまで考慮したときにもWindows認証って安全なのですか？
オレオレ認証局と同じような問題をはらんでいる気がするのですけど。

---

http://blogs.wankuma.com/hatsune/

Answer 10

皆様

ご回答ありがとうございました。
大変勉強になりました。

独自証明書を使うと危ないということが
理解できました。
ありがとうございました。

現在はDBサーバーにユーザーIDとパスワードの組み合わせを保持しています。
今まではWindowsフォームアプリケーションでシステムを作っていたのですが、
特に盗聴対策はしていませんでした。

今回Webアプリ化するため、
これを機にパスワードの暗号化を検討していました。

もし独自証明書を作成したとしても
各クライアントに証明書の配布が必要になりますよね。
私の当初の想いとしては（書いていませんでしたが。。。）
クライアントへの設定は”全く”せずにしたいと思っていたため、
証明書の配布は厳しいです。

端末数も1000台以上あるため、今からActive Directoryを構築するのも
なかなか大変で、対応すべきか悩んでしまいます。

今後の対応方法については、
皆様から教えて頂いた情報を元に、再検討したいと思います。
SSLにするのであれば、有償の証明書を購入します。

ご回答ありがとうございました。

Answer 11

解ってない扱いされちゃってますがもう一度出てきてみました。

>セッションが確立してからの盗聴は難しいですが、「AからBへの通信の開始時に相手がBである事が正しいという検証ができない」ために、AがAでなくてもBからはわかりません。

これは自分も書いている通りでもちろん理解していますよ。

しかし、man-in-the-middle attack は厳密には盗聴ではありません、盗聴手法の一端として紹介される事があるだけで、そもそもの通信相手が中間者に向いているのですから厳密にいえば盗聴という以前の通信相手の取り違えです。
この辺りを確認する為に「盗聴をどういう意味で使っていますか？」と聞いたわけです。

んで、SSLで信頼された証明機関から入手した証明書を利用すれば問題ないというのはまた間違いです。

中継者C が利用する偽物証明書の証明機関を A のルート証明書ストアに入れてしまえば A とはまるで正規の証明書のごとく A-C間のSSL通信は開始されますので正規証明書を入れれば大丈夫と思考停止しては A-B 間のセッションは守れません。
SSLを安全に運用するには端点のルート証明書ストア、利用する証明機関、証明機関から端点へ証明書を届ける方法のすべてをちゃんと守る必要があり、それさえちゃんと行われていればそれがオレオレ証明であろうが、本当の証明機関から提供された証明書であろうが信頼度は一緒です。
イントラネットワーク上に独自証明機関を立ち上げ、その独自証明機関の証明書を端点となる端末のルート証明書ストアへグループポリシーで配布し、Webサーバでその独自証明機関発行の証明書を使う事で正規の証明書を使ったとします。クライアントはルート証明書ストアに入った証明機関発行の証明書を提示されますので正規のSSLと変わらずにシステムを使えます。そして、このシステムは独自証明機関発行のオレオレ証明を使っているにもかかわらず本質的に安全です。

本質的に安全というのはセキュリティ上で本来は守る事になっている物が守られている間は安全という事で、独自証明機関の秘密鍵が漏れるとか端点のルート証明書ストアが攻撃者に触られるという事の無い前提です。(それが起これば正規の証明書でも破綻するので正規証明書と本質的な安全度は変わらない）
さて、証明機関の安全を保つ為の管理等が必要作業として発生してきました、この必要作業を行うのが正規の証明書の発行主体の役割ですので此処に要するコストを考えましょう、それが正規の証明書を利用するべきか、独自証明を利用するかの分岐点です安全に独自証明をイントラで運用できないという事ではないのです。（私はお勧めはしていないですよ、証明機関が破られた場合の損害は莫大になる可能性があり、イントラ上の数１００～数１０００を超えるシステムを展開していて外部から証明書を買うコストが十分に高い場合には採算する事があるという意味です）


さて、佐祐理さんお勧めのWindows 認証プロバイダは man-in-the-middle attack に安全なのでしょうか。

Windows NTLM認証とマン・イン・ザ・ミドル攻撃　http://www.st.rim.or.jp/~shio/csm/ntlm/

Active-Directory を構成していない
Active-Directory を構成していても Windows 2000ダウンレベル認証を許可している
Active-Directory を構成していてもドメインユーザーでないローカルマシンユーザーを認証している( AD 標準の Kerberos ではなく NTLM認証が利用される）
　SMB署名等のセキュリティ保護を行っていない

このような場合には Windows認証プロバイダは man-in-the-middle attackに対して脆弱です。

どんなシステムを使うにしてもセキュリティは安全な条件があります。安全条件が満たせるのかを十分に確認せずに何は危険とか、これは安全とかの話しをするのが一番の「解っていない」人の行動だと思いますがどうでしょう。

---

Kazuhiko Kikuchi

Answer 12

私のスタンスとしては、危険性を理解しないならば使うべきではない、です。もともと攻撃手段を説明する気はなく、別の手段としてWindows認証を提案しました。ただ、お二方とも安全と受け取れることを書かれているので、攻撃手段の１つを紹介しただけですよ。

「なりすましと説明せずに盗聴されると書いても意図が伝わらない」って逆でしょう。具体的な攻撃手段を知らないから安全であると言いふらすのは問題です。

Windows認証は１方向ハッシュであり、盗聴を行ったとしても平文パスワードに復号することができません。そのため、盗聴だけでなくWebサーバプロセスが乗っ取られていたとしてもそれでもなおパスワードは安全です。
# OSそのものが乗っ取られていた場合はちょっとわかりません。たぶん大丈夫だと思いますが。

多少言い逃れですが、質問は「パスワードを平文で送信したくない」つまりパスワードの保護であり、コンテンツの保護ではありません。

Answer 13

>端末数も1000台以上あるため、今からActive Directoryを構築するのも
>なかなか大変で、対応すべきか悩んでしまいます。

　ぜひ Active-Directory にしてください。端点となる端末のルート証明書ストアが改竄の対象になれば
正規のSSL証明書を利用したとしても無意味です。Active-Directoryではグループポリシーによって
クライアントのルート証明書ストアを一括管理できます。

　SSLを正規証明書を使うにしてもオレオレ証明を使うにしてもどっちにしてもルート証明書ストアを守り続ける
コストは必要ですので、そのためのセキュリティをクライアント端末まで張り巡らせるという選択肢をとるならば
ADの導入は1000台以上の端末のルート証明書ストアを守るには最もリーズナブルな投資と思います。

　逆にクライアントネットワーク全域は守れないという前提に立ちWindowsフォームアプリケーションでシステム
を作っているならば公開鍵暗号キーペアを作り、アプリケーションに公開鍵をリソースとして埋め込んでしまう
方が良いでしょう。サーバに秘密鍵を置いてサーバにある秘密鍵を死守する前提に立てばサーバ以外の誰も
暗号を解く事はできませんので守るべき範囲を最小に抑えてシステム全体のセキュリティを設計できます。
　また埋め込んだリソース中の公開鍵を使って通信してくる偽端末をどうはじくかはサーバのセキュリティ設計
として実施してください。これはSSLでも一緒です。通信レイヤにおける暗号で安全になるのは端点間の経路で
あって端点の向こう側に正しい端末がつながっているのかは別問題だからです。

---

Kazuhiko Kikuchi

Answer 14

外池です。えぇ、あのですね、みなさん、それぞれによくご存知で（私は、全然アマチュア、ゆえに「オレオレ証明書」でなんとかなる程度のことしかできない）。

ただ、この手の議論にありがちな、みなさんそれぞれが暗黙のうちに前提にしている条件がお互いに伝わっていなかった、ということでよろしいんじゃないですか？　（私の場合、「盗聴」という言葉は、サーバー、クライアント間の通信をパッシブに傍受する、という意味で使いました。間に割って入る、つまり一般的に言って、通信を横取りした上で偽装して送出することは意味していません。）

１）認証情報も含めた通信の暗号化には、SSL通信が有効である。
（通信の傍受対策には有効だが、サーバーの偽装対策には不十分）

２）パスワードのみの暗号化であれば、Windows認証が有効である。
（認証情報の保護には有効だが、通信が傍受されると中身は筒抜け）

３）通信相手（この場合サーバー）の偽装の防止には、証明書が有効である。ちゃんと認証機関にまでたどり着ける証明書でも、オレオレ証明書であっても有効だが、いずれの場合も、証明書の発行と配布の手続きを適切に管理しなければならない。一般的に、認証機関による証明書が楽とは思われるが、それでも、証明機関への依頼と証明書の受領、秘密鍵の管理、証明書の配布は、やはり、厳密な管理が必要。
（これは通信相手の実在性の問題の議論。）

で・・・、リオさんが守ろうとしているのは何なのか？　によって、どこまでやるかはリオさん次第ということかと。
確かに、元のお題からすれば、２）ですね。

---

（ホームページを再開しました）

Answer 15

どんなシステムを使うにしてもセキュリティは安全な条件があります。安全条件が満たせるのかを十分に確認せずに何は危険とか、これは安全とかの話しをするのが一番の「解っていない」人の行動だと思いますがどうでしょう。

えーっと、セッション確立前について言及せず、暗黙のうちにセッション確立後に限定した上で「自分の認識ではたとえオレオレ証明を使っても盗聴はされないと認識してますけど。」と書いて、安全であるかのように誤解させる記述をする方のことを指してますか？

後出しなら何でも言えますよね。私は「詳しく説明せず安易にオレオレ証明書によるSSL通信を勧める人」に対して釘を刺したかっただけです。それでもなお勧める人がいた、それだけのことです。

Answer 16

皆様

ご回答ありがとうございました。

少し内容が難しいため、すべては理解できませんでしたが、
どうすべきかは理解できました。

> で・・・、リオさんが守ろうとしているのは何なのか？　によって、どこまでやるかはリオさん次第ということかと。
> 確かに、元のお題からすれば、２）ですね。

私が守ろうとしているのは、２）でして、
パスワードのみの暗号化を求めています。
コンテンツは盗聴されても構わないと思っております。

そうなるとWindows認証が有効なのですね。
とても勉強になりました。

Active Directory側でユーザーとパスワードを管理して、
Windows認証をさせれば、パスワードが平文で送信されることがないため、
安全だということですね。

皆様の議論を見て、
セキュリティ対策の大切さを改めて感じさせて頂きました。

大変勉強になりました。
ご回答ありがとうございました。

Answer 17

> Active Directory側でユーザーとパスワードを管理して、
> Windows認証をさせれば、パスワードが平文で送信されることがないため、
> 安全だということですね。

それで社内イントラネット内の Web サイトへのアクセスは問題なくなるとして、メールはどうしてますか？

パスワードはすべて同じという人が多いと思いますが、メールの送受信の際に、それが平文でネットワークを
流れているということはないでしょうか？

Answer 18

自分の最初の返信から引用しますね

--
SSLを利用する上でオレオレ証明を使う問題はAからBへの通信の開始時に相手がBである事が正しいという検証ができないだけで、AとB(かもしれないだれか）で確立されたセッション上で流れているデータは盗聴できないはずです。
--

>えーっと、セッション確立前について言及せず、暗黙のうちにセッション確立後に限定した上で「自分の認識ではたとえオレオレ証明を使っても盗聴はされないと認識してますけど。」と書いて、安全であるかのように誤解させる記述をする方のことを指してますか？

通信の開始時と平易な表現をしましたがセッション確立時について言及していますが。
そして、「盗聴をどういう意味で使っていますか？」と確認をしただけで解ってない扱いをされたわけでして、後だしなら何でも言えるというような言い方をされるのは心外ですね。

---

Kazuhiko Kikuchi

Answer 19

たぶん、kazukさんじゃなくて私の事を言いたいんじゃないかな。

＞えーっと、セッション確立前について言及せず、暗黙のうちにセッション確立後に限定した上で

元々の質問が「パスワードを平文でネットワーク上に送信したくないという要望があります。」だったので、当初の回答は、社内イントラネットということで「なりすまし」の事は考慮してなかったのは事実です。まあ、その点については考えが至ってないという指摘については反論するつもりは全然ないのですが。

なので、Windows認証とオレオレ認証によるhttpsは同等と見なして、現状でWindows認証をしてないならhttpsの方が一番なんじゃ？という回答になったわけです。

その後、同等じゃないよということだったので、なりすましのことですか？って確認したら、まあ、同じように解ってない後だしならなんとでも言えると言われている訳です(笑）。

---

http://blogs.wankuma.com/hatsune/

Answer 20

SurferOnWwwさん

ご回答ありがとうございます。
確かにそうですね。
メールのパスワードも平文でネットワークに流すことは問題ですね。

私はメールの担当ではありませんが、
確かに連携して対応する必要がありそうですね。
私だけで対応しても、あまり効果的な対応とならない可能性がありますもんね。

この点注意して対応方法を検討したいと思います。
ありがとうございました。