MITコース「コンピューターシステムのセキュリティ」。 講義17：ユーザー認証、パート1

マサチューセッツ工科大学。 講義コース6.858。 「コンピューターシステムのセキュリティ。」 ニコライ・ゼルドヴィッチ、ジェームズ・ミケンズ。 2014年

コンピューターシステムセキュリティは、安全なコンピューターシステムの開発と実装に関するコースです。 講義では、脅威モデル、セキュリティを危険にさらす攻撃、および最近の科学的研究に基づいたセキュリティ技術を扱います。 トピックには、オペレーティングシステム（OS）セキュリティ、機能、情報フロー管理、言語セキュリティ、ネットワークプロトコル、ハードウェアセキュリティ、およびWebアプリケーションセキュリティが含まれます。



講義1：「はじめに：脅威モデル」 パート1 / パート2 / パート3

講義2：「ハッカー攻撃の制御」 パート1 / パート2 / パート3

講義3：「バッファオーバーフロー：エクスプロイトと保護」 パート1 / パート2 / パート3

講義4：「特権の共有」 パート1 / パート2 / パート3

講義5：「セキュリティシステムはどこから来たのか？」 パート1 / パート2

講義6：「機会」 パート1 / パート2 / パート3

講義7：「ネイティブクライアントサンドボックス」 パート1 / パート2 / パート3

講義8：「ネットワークセキュリティモデル」 パート1 / パート2 / パート3

講義9：「Webアプリケーションのセキュリティ」 パート1 / パート2 / パート3

講義10：「シンボリック実行」 パート1 / パート2 / パート3

講義11：「Ur / Webプログラミング言語」 パート1 / パート2 / パート3

講義12：ネットワークセキュリティパート1 / パート2 / パート3

講義13：「ネットワークプロトコル」 パート1 / パート2 / パート3

講義14：「SSLおよびHTTPS」 パート1 / パート2 / パート3

講義15：「医療ソフトウェア」 パート1 / パート2 / パート3

講義16：「サイドチャネル攻撃」 パート1 / パート2 / パート3

講義17：「ユーザー認証」 パート1 / パート2 / パート3



それでは始めましょう。 あなたの帰国により、すべての人の休日が成功したことを願っています。 今日はユーザー認証についてお話します。 だから、講義のトピックは、ユーザーがプログラムに対して自分のアイデンティティを証明する方法を見つけることですか？ 特に、今日のレッスンを対象とするこの記事は、セキュリティコミュニティの存在の基礎に触れています。 パスワードよりも認証に良いものはありますか？







最高レベルでは、パスワードは非常に低いエントロピーを持ち、攻撃者がパスワードを簡単に解決できるため、ひどい考えだと思われます。 忘れたパスワードを回復するために使用する秘密の質問は、パスワード自体よりもエントロピーが低く、これも問題のようです。



さらに悪いことに、ユーザーは通常、多くの異なるサイトで同じパスワードを使用します。 これは、簡単に推測されるパスワードに脆弱性があると、多くのサイトでのユーザーの作業が危険にさらされることを意味します。



今日の講義の記事から引用した次の引用が気に入りました。「ユーザー認証の他のすべての方法の中でパスワードが継続的に支配されていることが、セキュリティ研究の主な難しさです。」 したがって、セキュリティ研究コミュニティは、パスワードよりも優れた代替手段を求めています。 ただし、より便利で、より広く、より安全でありながら、パスワードを完全に置き換えることができる認証スキームが本当にあるかどうかは不明です。



今日は3つの質問を検討します。 まず、既存のパスワードがどのように機能するかを見ていきます。 その後、任意の認証スキームでグローバルに必要なパスワードプロパティについて説明します。 最後に、メトリクス、または認証機能に関する講義記事の内容と、他のいくつかの認証スキームがパスワードとの効率の点でどのように比較されるかを調べます。







それでは、パスワードとは何ですか？ パスワードは、ユーザーとサーバーの共有秘密です。 したがって、パスワードスキームの基本的な実装には、基本的に、ユーザー名をパスワードにマッピングするサーバー側のテーブルが必要です。



これは、認証スキームの1つの実装を想像する最も簡単な方法です。ユーザーは自分の名前とパスワードを入力し、サーバーはこのテーブルでそれらを探し、パスワードを名前と比較し、すべてが一致する場合、ユーザーが認証されます。 明らかに、問題は、攻撃者がサーバーに侵入した場合、このテーブルを見て、すべてのパスワードを引き継ぐことができるということです。 したがって、これは明らかに悪いことです。



おそらく、この問題の解決策は、次のようなサーバーにテーブルを保存することです。ユーザー名はパスワード自体ではなく、ハッシュに対応しています。 この場合、ユーザーはパスワードをプレーンテキストで入力し、サーバーはハッシュコードをチェックして、テーブル内の値と比較します。 このスキームの利点は、これらのハッシュ関数が、ハッシュをパスワードに変換するのが困難になるように設計されていることです。 このテーブルが失われた場合、データリークが発生した場合、または攻撃者がサーバーをハッキングして所有した場合、テキストパスワードの代わりにランダムな英数字の文字列が表示され、元の画像を復元することは困難になります。



少なくとも理論的には、ハッシュの使用は非常に良いことです。 しかし、実際には、攻撃者はブルートフォース攻撃を使用してハッシュ値の逆イメージを決定する必要はありません。







攻撃者は、実際にはパスワードの分布が不均一であるという事実を実際に利用できます。 そして、不均等な分布によって、つまり...すべてのパスワードが最大20文字の長さであることを知っているとしましょう。 実際には、ユーザーはこの範囲全体を使用せず、123、toddなどのパスワードを好みます。 ただし、実証的な研究により、このようなパスワードの仕組みが示されており、ユーザーの約20％が5000の最も一般的なパスワードを使用していることがわかりました。 言い換えれば、これは、攻撃者がこれらの5,000個のパスワードのデータベースを持っている場合、それらを簡単にハッシュし、盗まれたパスワードテーブルを表示するときに、単にハッシュを照合できることを意味します。 経験的に、ハッカーはサーバーテーブルにあるパスワードの約20％を回復できます。



Yahooの専門家は、パスワードには10〜20ビットのエントロピー、10〜20ビットのランダム性が含まれていることを発見しました。 実際、これはそれほど多くありません。 ハッシュ関数の作成の複雑さを考慮して、最新のマシンは毎秒数百万のそのようなハッシュを計算します。 したがって、コンピューターがパスワードを簡単にハッシュできるように、ハッシュ関数は設計で簡単に計算可能でなければなりません。 ただし、この事実とパスワードのランダム性が不十分であるという組み合わせは、原則として、このスキームは見かけほど安全ではないことを意味します。



ハッカーの生活を複雑にしようとすることがあります-これはキーを生成する複雑な機能です。 この場合、パスワードハッシュがソースデータとして使用され、それに基づいてサーバーがサーバーに格納されるキーを生成します。







これらのキー生成関数の良い点は、カスタマイズ可能な複雑さです。つまり、特定のノブを回すと、プロセスのパフォーマンスをどれだけ節約したいかによって、この関数の動作を遅くしたり速くしたりできます。



キーを生成するとします。 例としては、PBKDF2キー生成標準、または場合によってはBCryptがあります。これらについては、インターネットから詳細を知ることができます。 これらのキー生成関数の1つが、計算に数ミリ秒ではなく、1秒を要すると想像してください。 実際、5000個の「トップ」パスワードの値を生成しようとすると、はるかに長い時間がかかるため、これにより攻撃者の作業がはるかに困難になります。



内部レベルでは、これらのキー生成関数は多くの場合、ハッシュを繰り返し呼び出して何度もアクセスすることで機能するため、すべてが非常に単純です。 しかし、時間のかかるキー生成プロセスを使用することで、私たちが直面しているセキュリティの問題を解決できますか？ 問題の1つは、敵がレインボーテーブルまたは「レインボーテーブル」と呼ばれるものを構築できることです。 レインボーテーブルは、単にパスワードがハッシュ値と一致する方法のマップです。 したがって、システムがこれらの高価なキー生成関数の1つを使用している場合でも、攻撃者はこれらのテーブルの1つを一度計算できます。 各キー生成関数の処理はかなり遅いため、これは少し複雑になりますが、攻撃者はこのテーブルを一度作成し、それを使用して同じキー生成関数アルゴリズムに基づいてすべての後続システムをクラックできます。 これが、これらのレインボーテーブルの仕組みです。



繰り返しますが、Rainbowテーブルを作成することの経済的利益を最大化するために、攻撃者は先ほどお話ししたパスワードの不均一な配布を利用できます。 したがって、攻撃者は、可能なすべてのパスワードの小さなセットに対してのみこのようなテーブルを構築できます。



学生：おそらく「塩漬け」はそれをずっと難しくしますか？



教授：はい、はい、正確に。 数秒後に「塩漬け」に行きます。 一般に、ソルティングを使用しない場合、レインボーテーブルを使用すると、攻撃者はオフラインで多少の努力をしてこのテーブルを計算し、実行された作業に基づいて基本パスワードを計算できるようになります。



状況を改善するために次に考えられることは、塩漬けです。 どのように機能しますか？ 基本的な原則は、パスワード生成方法にランダム性を追加することです。 このハッシュ関数を使用して、その中に「塩」、次にパスワードを入れます。これらはすべてサーバー上のテーブルに保存されます。







塩とは？ これは、このハッシュ関数の最初の部分を表す単なる長い文字列です。 では、なぜこのスキームを使用した方が良いのでしょうか？ 実際には、ソルトはクリアテキストでサーバー側に保存されることに注意してください。 この「塩」がサーバー側にクリアテキストで保存されていて、攻撃者がパスワードのユーザー名のテーブルを盗むことができるとしたら、なぜこの「塩」も盗むことができないのでしょうか。 そのようなソリューションの用途は何ですか？



学生：最も一般的なパスワードを選択した場合、一度だけ使用して新しいユーザーを見つけることはできないためです。

教授：絶対に正しい。 基本的に、ソルトが行うことは、攻撃者がすべてのハッシュに対して使用できる単一のレインボーテーブルを作成するのを防ぐことです。 原則として、「塩」は同じパスワードでも一意にする方法と考えることができます。 実際には、多くのシステムが「塩漬け」の概念を使用しています。



実際、「塩」を使用すると、この擬似パスワードにできるだけ多くのビットを追加することができます。ビットが多いほど良いためです。 他に必要なことは、ユーザーがパスワードを変更するたびに「塩」も変更する必要があることを考慮することです。 この決定の理由の1つは、同じパスワードを数回使用したいユーザーの怠だからです。 「塩」を変更すると、1つのパスワードがまったく同じパスワードに置き換えられた場合でも、パスワードデータベースに保存されているものが実際に異なることが保証されます。



観客：なぜ「塩」と呼ばれるのですか？



教授：これは良い質問です。確かに答えられません。 ただし、これには正当な理由があると確信しています。 CookieがCookieと呼ばれるのはなぜですか？ インターネットはおそらくその理由を知っていますが、私にはわかりません。



学生：おそらく「塩」がハッシュに「味」を少し追加するからでしょうか？



教授：まあ、映画賞を受賞する機会があるのは明らかだから、これを撮影できてうれしい。 インターネットには何らかの答えがあると確信しているので、後で探します。

したがって、上記のアプローチは非常に簡単です。 ユーザーが何らかの方法でサーバーにパスワードを送信すると想定しましたが、これがどのように発生するかを指定しませんでした。 では、これらのパスワードをどのように渡すのでしょうか？



まず、パスワードをネットワーク経由でクリアテキストで送信するだけです。 送信するトラフィックを監視する侵入者がネットワーク上に存在する可能性があるため、これは悪いことです。 彼は単にパスワードを割り当てて、あなたになりすますことができます。



したがって、私たちは常に1人のストローマンから始めます。他のストローマンを紹介する前に、もちろん致命的な欠陥があります。 したがって、最初に考えられるのは、パスワードをクリアテキストで送信することです。 セキュリティの観点からは、暗号化された接続を介してパスワードを送信する方がはるかに優れているため、暗号化を使用します。 ネットワーク上で送信する前にパスワードを変換するために使用される何らかの種類の秘密キーがある可能性があります。 そのため、最高レベルでは、製品の品質を保証する商標のように、暗号化は常により良いことをしているようです。



しかし、問題は、暗号化とハッシュの使用方法を慎重に考えないと、期待しているセキュリティ上の利点を活用できないことです。 たとえば、ユーザーとサーバー、この悪名高い攻撃者、サーバーのふりをしながら実際にトラフィックを監視する「中間者」の間にあなたの間に座っている誰かがいる場合。



相手側を認証せずに暗号化されたデータを送信すると、問題が発生する可能性があります。 クライアントは単にランダムなキーを選択し、それをサーバーである場合とそうでない場合がある反対側の宛先に送信するためです。



事実、あなたは誰かに何かを送って、その後、あなたのすべての秘密を手に入れる機会を得るでしょう。



これを考えると、人々はパスワード自体ではなく、ハッシュを送信する方がはるかに良いと考えるかもしれません。 実際、これだけでは何も得られません。パスワードを送信するかパスワードハッシュを送信するかに関係なく、このパスワードハッシュは元のパスワードと同じ意味の力を持ち、サーバーを認証していない場合は役に立ちません。



そのため、重要なことは、暗号化を追加したり、ハッシュを追加しただけでは、セキュリティ上の利点が必ずしも得られるとは限らないということです。 クライアントがパスワードの送信先を認証できない場合、クライアントはパスワードを開示するつもりのない人に誤ってパスワードを開示する可能性があります。



したがって、おそらく以前の2つの方法よりも優れたアイデアは、いわゆるチャレンジ/レスポンスプロトコル、またはチャレンジ/レスポンスプロトコルを使用することです。 これは非常に単純な呼び出し/応答プロトコルの例です。 ここにクライアントがあり、ここにサーバーがあります。 クライアントはサーバーに「Hi、I am Alice」と伝えます。その後、サーバーはコールCで応答します。その後、クライアントはサーバーから送信されたこのコールのハッシュで応答し、パスワードと組み合わせます。







サーバーは答えを知っているので、現時点ではサーバーはこのシーケンス（クライアントの応答）を受け入れることができます。 また、サーバーは送信したチャレンジと、おそらくパスワードを知っているため、サーバーは受信したハッシュの値を計算し、ユーザーが送信したものと実際に一致することを確認できます。



このプロトコルのプラスの特徴は、「中間者」の存在を一瞬無視すると、このパスワードを知っているのはアリスだけなので、サーバーはユーザーが本当にアリスであることを確認することです。 同時に、アリスがこのことをサーバーではなく、サーバーのふりをした人に送信した場合、彼はパスワードを知りません。 攻撃者はCを使用できますが、パスワードをまだ知らないため、パスワードを見つけるために、このハッシュ関数を再度反転させる必要があります。 ご質問はありますか？



学生：サーバーにパスワードを送信し、ハッシュされたサーバー呼び出しを受信する代わりに、クライアントは単にハッシュされたパスワードをサーバーに送信できますか？



教授：つまり、クライアントが単にハッシュされたパスワードをサーバーに送信しないのはなぜですか？ これには2つの理由があります。 後で説明します。これはアンチハンマリング保護と呼ばれ、「悪い」クライアントから防御するために作成され、「これはパスワードですか、これはパスワードですか、これはパスワードですか？」 この認証メカニズムにより、サーバーとクライアントの両方のプロセスが簡素化されますが、JavaScriptなどを使用して、基本的にクライアント側でハッシュを作成できます。 しかし、基本的な考え方は、攻撃者がパスワードをすばやく推測するのを防ぐために、何らかの方法で認証の最大の複雑さを確保する必要があるということです。 他に質問はありますか？







学生：クライアントがハッシュを実行したとしても、誰かがサーバーテーブルを制御してハッシュに使用すると、ネットワークに入ることができることに注意したいだけです。



教授：絶対に正しい。 はい、誰がこのコールCを所有できるかによって少し危険になります。クライアントとサーバーがこのCの値を選択できる場合、クライアントがそのような攻撃を組織することが難しくなるためです。 このプロトコルの使用に関する問題の1つは、クライアントがこのHCC値をランダム化できないことです。 クライアントがHCC部分でC呼び出しを選択できる場合、サーバーがこのプロトコルをより困難にすることができると想像できますが、この場合、クライアント呼び出しとサーバー呼び出しが並置されます。

これ以上質問がない場合は、クライアントからサーバーへのパスワード転送メカニズムの説明を終了したと想定します。 サーバーはクライアントから受け取ったハッシュとパスワードを逆にする必要があるという事実にもかかわらず、攻撃者はブルートフォース攻撃を実行しようとすることができ、前述の高価なハッシュ関数の1つを使用するだけでこの種の攻撃からサーバーを保護できます。



, , , HCC. , «». « ».



, , , , « ». «» , « » .



Antihammer – , , . , , brute-force , . , Antihammer – , , : « ».







-, . , 10 , : « 10 , ». . «» , TPN . ? – , , , .

, , , - . , , - , , . – . , , .



, — , , — . , , . , . , , .



, , , Dictionary attack, « ». , , Microsoft Telepathwords. . , , , Telepathwords , . , , , , .







«», , , , , «».







«» , . Telepathwords? , , . , .







, . , , . , .



, Telepathwords , , , , , . .

, — , , , .



: , , IP- , Antihammer .



: , . Antihammer IP-, , . , Antihammer , – . , Antihammer , , , , , , .



, . , . , .



: Antihammer? , , ? , , SRP Zero Knowledge Protocol, ZKP, …



: , ?



: ?



:はい、使用します。これらのプロトコルは、より強力な暗号化保証を提供します。ほとんどの場合、現在のシステムとの下位互換性がないため、実際には使用頻度に気づきません。しかし、実際に実際に使用されるZKPなど、サーバーがパスワードが何であるかをまったく知らないようにするプロトコルがいくつかあります。



27:20分



MITコース「コンピューターシステムのセキュリティ」。 講義17：ユーザー認証、パート2





コースの完全版はこちらから入手できます 。



ご滞在いただきありがとうございます。 私たちの記事が好きですか？ より興味深い資料を見たいですか？ 注文するか、友人に推薦することで、私たちをサポートします。私たちがあなたのために発明したエントリーレベルのサーバーのユニークなアナログのHabrユーザーのために30％の割引： VPS（KVM）E5-2650 v4（6コア）についての真実20ドルまたはサーバーを分割する方法？ （オプションはRAID1およびRAID10、最大24コア、最大40GB DDR4で利用可能です）。



VPS（KVM）E5-2650 v4（6コア）10GB DDR4 240GB SSD 1Gbpsまで 6か月の期間を支払う場合は12月まで無料で 、 ここで注文できます 。



Dell R730xdは2倍安いですか？ オランダと米国で249ドルからIntel Dodeca-Core Xeon E5-2650v4 128GB DDR4 6x480GB SSD 1Gbps 100 TVを2台持っているだけです！ インフラストラクチャビルの構築方法について読んでください。 クラスRは、1米ドルで9,000ユーロのDell R730xd E5-2650 v4サーバーを使用していますか？